Когда и как нужно применять многопоточность?

не нужно.

1 - интерфейс, 2 - остальное.

в идеале нужно делить на потоки те задачи, которые не зависят друг от друга:
допустим у нас есть несколько аккаунтов на разных серваках - очевидно, что авторизацию и прочее можно распараллелить посервачно (прости, Саша).
авторизацию в конфах так же можно (точнее нужно - привет, псина, мать твою) распараллелить
...
и т.д. и т.п.
вообще вопрос похож на троллинг

херовый совет
очень херовый

конечно не нужно. многопоточность нужна для повышения производительности, а не для того, чтобы использовать ее для многопоточности.

в идеале нужно делить на потоки те задачи, которые не зависят друг от друга:

в идеале нельзя наступать на трещины в асфальте.

//fixed

Не совсем понял. Ты хочешь 2 разных GUI потока что ли? Такое возможно только в WxErlang.

Потоки нужно применять либо когда разнесение алгоритма по нескольким процессорам позволит увеличить его производительность, либо когда нужно избавиться от блокирующих вызовов, улучшив, например, user expirience (в этом случае, вообще говоря, удобней пользоваться неблокирующими вызовами, но не во всех языках есть хорошая поддержка этой парадигмы).

Такое возможно только в WxErlang.

http://blog.borovsak.si/2009/06/multi-threaded-gtk-applications.html

Если затуп не в отрисовке, а в обновлении данных, помогает. Например, надо в окне нарисовать результат долгих вычислений. Разумеется, пока всё вычисляется интерфейс должен продолжать реагировать на кнопки, а не впадать в кому.

Ну а если затуп в отрисовке, то опять же, никто не мешает в отдельном потоке готовить картинку, а через GUI её просто показывать.

либо когда разнесение алгоритма по нескольким процессорам позволит увеличить его производительность, либо когда нужно избавиться от блокирующих вызовов

Пропущен вариант «улучшить время отклика». Тривиальный пример с браузером: если рендер делать в основном потоке, то пока страница не отрисуется, всё будет висеть. Из-за этого, кстати, очень неудобно делать глобальную обработку текста в Emacs'е (Запустил поиск/замену по регекспу и приходится для редактирования следующего файла отдельный Emacs запускать. Хорошо, хоть внешние процессы асинхронно запускаются).

Пропущен вариант «улучшить время отклика». Тривиальный пример с браузером: если рендер делать в основном потоке, то пока страница не отрисуется, всё будет висеть. Из-за этого, кстати, очень неудобно делать глобальную обработку текста в Emacs'е (Запустил поиск/замену по регекспу и приходится для редактирования следующего файла отдельный Emacs запускать. Хорошо, хоть внешние процессы асинхронно запускаются).

Ваши вариации на тему все равно укладываются в те два варианта, которые описал Legioner. Не следует понимать блокировку буквально, как ожидание процессом завершения системного вызова ядром. Ваше «если рендер делать в основном потоке, то пока страница не отрисуется, всё будет висеть» по сути та же блокировка, только в данном случае блокируется не процесс как таковой, а отдельные функциональные возможности. Но хрен редьки не слаще. Так что как ни крути, а многопоточность нужна/полезна в двух указанных случаях.

Пропущен вариант «улучшить время отклика»

Это и называется блокирующий вызов. Собственно, как сказал товарищ Legioner, многопоточность применяется только в двух случаях: увеличение производительности путём распределения ресурсов по процессорам и обход (потенциально) блокирующих вызовов. Остальное попадает в эти категории.

Есть конечно ещё случай с отсутствием синхронного API как такового. К примеру, в библиотеку приходят каллбеки, из которых нужно сразу выйти, но они могут стартовать вспомогательный поток, чтобы в фоне пожевать какой-то код. Опять же, это вариант обхода блокировки.

Можно. Но не нужно.

Cast rht

Вот допустим пишем мы мессенджер, нужно ли френдлист и окно диалога делить

Я бы поделил. Должно бы упростить реализацию, но это зависит и от скиллзов конкретного индивидуума.

Должно бы упростить реализацию

Многопоточность? Упростить? Ты уверен?

Речь же не про модульность, а про отдельные потоки на обработку интерфейсных объектов.

Многопоточность? Упростить? Ты уверен?

Не, не уверен. Особенно если ТС имеет в виду интерфейс. В них я ни бум-бум.

Когда выигрыш от ее использования больше, чем неустранимые накладные расходы :) Гуй вполне работоспособен в одном потоке, максимум - асинхронные замутки.

Зависит от языка. В нормальных (Erlang, Haskell) можно выделять поток хоть на каждый пук, если это удобно. В убогих при количестве потоков > 2 код превращается в нечитаемую лапшу -> многопоточность применяют только для «обхода блокирующих вызовов» и «улучшения производительности».

При современных мощностях писать многопоточные мессенгеры жесть, однозначно.

Я пишу, бывает, системные штучки. Вот, у нас был проект, я там делал сетевой многопоточный интерфейс. Управляющий компьютер - маломощный терминал, генерировал запросы к распределённой БД. У меня запрос распараллеливался, после выборки «собирался в кучу» и посылался на «вычислитель» - мощный комп.

А может лучше на процессы? :)

А может лучше на процессы

Кстати, вопрос в тему. Насколько пристойно для программы создать 3-4 десятка разных процессов. С производительностью всё ок, но в ps всё это будет видно. В примитивном варианте как у qmail:

svscan /service
            supervise smtpd
              /usr/local/bin/tcpserver -vDUHR -lyour.host -xtcp.cdb -- 0 25 ...
            supervise log
              multilog t ./main

Но теперь всё то же на задачи нормального приложения: logger, monitor, network (х соединения), gui (х количество пользователей), db-connect (х количество открытых баз) и т. д.

Вопрос такой: насколько такая программа была бы удобной для сисадмина?

Вот допустим пишем мы мессенджер

За сетевое взаимодействие в потоке с GUI надо бить по рукам.

Делить на потоки стоит:
1. Когда это увеличит производительность приложения.
2. Когда это увеличит отзывчивость интерфейса.

Во всех остальных случаях она вредна.

не во всех языках есть хорошая поддержка этой парадигмы

poll можно дёрнуть практически везде.

Это неудобно. Удобно сделано в node js, в блокирующую функцию передаётся коллбэк, который вызывается, когда готов результат. Можно ещё удобней, если есть возможность использовать продолжения. Именно это я имел в виду под хорошей поддержкой. Например в Java обещают в будущем поддержку.

Как продолжения позволяют делать асинхронность? А за колбечную паутину минус тебе.

Я шокирован оветами. В случае мессенейджера, в отдельные потоки нужно выделять такие задачи, как: 1) загрузка френдлиста с сервака; 2) загрузка информации о пользователе; 3) загрузка историй сообщений... Другими словами, все те задачи, которые имеют непредсказуемое время выполнения. После выполнения задачи уже следует обновить гуй. И да, GUI всегда в одном потоке выполняется.

Ты дебил и ничтожество.

А в твою тупую башку не приходит тривиальная мысль, что семантика задачи может быть изначально многопоточной (например, обменивающиеся асинхронными сообщениями агенты)?

потоки не нужны, все спокойно диспатчится последовательно + префорк.

В этом itt треде не прозвучало двух волшебных слов: concurrency и parallelism. Вас интересует первое, гуглите его. Ну и готовьтесь к тому, что многопоточный код богат удивительными факапами, которые больше нигде не увидеть, ключевые слова: data race, deadlock и т.д.

Очень толсто.

Не нужно это параллелить на потоках. То что ты говоришь делать надо асинхронно, а если упираешься в проц (что маловероятно на данной задаче), то запускать event-loop'ов по числу ядер.

Ещё один «программист»

Вот допустим пишем мы мессенджер, нужно ли френдлист и окно диалога делить на потоки?

Нет, это лишнее, а вот проверку орфографии, а именно работу с движком hunspell, enchant нужно делать в отдельном потоке.

Многопоточность нужна, когда один тред будет 100% насыщать процессор и одновременно всем потокам надо обращаться к большому общему хранилищу данных.
Месседжер вполне будет укладываться в один поток который обрабатывает события (сигналы в qt или select/poll для сети/файлов).
Отдельные задачи месседжера могут использовать много CPU: поиск по истории.
Такая задача обычно не требует передачи большого количества данных ( человек за одну «страницу» сможет посмотреть максимум 10к сообщений). Это значит что можно использовать как тред так и отдельный процесс.
Отдельный процесс (а ещё лучше отдельная утилита) предпочтительнее, т.к. предоставляет дополнительные возможности пользователю (cli) и изолирует разные по назначению куски кода.
В некоторых случаях полезно отделить реалтайм обработку, например голосовые/видео звонки, опять же может быть как процессом так и потоком.
Есть практика отделения gui потока от управляющего кода, позволяет пользователю нажать на закрыть приложение, даже при неучтённых синхронных вызовах: gethostbyname может висеть несколько секунд у пользователя, хотя разработчик может не замечать этой проблемы.
Это всё относится к месседжеру, для баз данных, очередей, http серверов ситуация с потоками/процессами/конечными автоматами совсем другая.

Ключевые слова - message passing. И никаких рейсов с дедлоками.

Возможно это будет для вас новостью, но в message passing модели дедлоки тоже возможны. От них как бы избавились в STM, но я мало где эту модель видел.

Обычно для того чтобы не возиться с синхронизацией существует очередь событий для графического интерфейса в одном потоке. Но если в каком либо обработчике события что-то делается долго, тогда нужно делать отдельный поток

Message passing должен быть асинхронным. Если никто никого не ждет, то и дедлока быть не может.

многопоточный код богат удивительными факапами, которые больше нигде не увидеть, ключевые слова: data race, deadlock и т.д.

Не поверите, в асинхронщине типа Twisted о них можно узнать гораздо быстрее. Потоки хороши во всём, кроме проблемы 10к. Но в мессенджере её и не возникает.

Когда препод задаёт, тогда и нужно.

А в твою тупую башку мысли вообще не приходят, но я же об этом не кричу на каждом углу.