LINUX.ORG.RU

Проектирование многопоточных приложений


0

4

Поделитесь ссылками(книги, блоги, статьи и тд) по сабжу. Интересует именно проектирование: как разбивать приложение на потоки, какие инструменты синхронизации использовать в каких ситуациях(блокирующие, неблокирующие и тд), какие модели потоков использовать(native, fiber).

fabers

Для начала выучить английский

anonymous ()

Интересует именно проектирование: как разбивать приложение на потоки

Гугли по ThreadPool и Grand Central Dispatch, как ни странно.

quiet_readonly ★★★★ ()

Книжки Java Concurrency In Practive, C++ Concurrency In Practice, итп)

stevejobs ★★★★☆ ()
Ответ на: комментарий от Dark_SavanT

Мсье идиот, или просто ограниченный и убогий? Дальше своих чмошных уеб-серверишек ничего видеть не желаешь, да?

anonymous ()
Ответ на: комментарий от anonymous

Я как-то дальше embedded слабо вижу, есть такая слабость. А тут FSM во все поля однака.

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

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от Dark_SavanT

Я как-то дальше embedded слабо вижу

Про Network-on-Chip не слыхал? Очень удобная модель, на одном современном FPGA до хрена ядер помещается.

но начинать кашу из мьютексов и прочих семафоров на каждый чих - увольте

RTFM про message passing и Pi calculus. Не надо никаких мутексов с семафорами.

Потоки нужны тогда, когда с ними становится проще чем с FSM

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

anonymous ()
Ответ на: комментарий от anonymous

Про Network-on-Chip не слыхал?

В современных реалиях вещь нечастая. Руками тыкать пока не доводилось.

RTFM про message passing и Pi calculus. Не надо никаких мутексов с семафорами.

Pi-calculus насколько я понял применять кроме как полтора безумных учёных никто не умеет. Message Passing - это хорошо, но накладные расходы в какой-то момент начинают быть заметны.

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

Не спорю. Только помним, что в реальном частном случае у нас потоки крутятся на одном ядре, что в итоге сводит все игрища с потоками (упрощённо) к переключению между кусками кода по прерыванию от таймера. И тут надо задать себе вопрос - хочешь ли ты «псевдоодновременное исполнение» и нужно ли оно тебе, или ты можешь обойтись eventloop по «прерываниям»(epoll к примеру или таймеры).

Когда появляется несколько физических исполнительных устройств, то message passing между процессами сразу начинает быть приличным решением.

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от Dark_SavanT

в реальном частном случае у нас потоки крутятся на одном ядре, что в итоге сводит все игрища с потоками (упрощённо) к переключению между кусками кода по прерыванию от таймера.

В реальном мире однопроцессорные системы редкость. И нет, я не о многоядерных системах, а о В/В.

tailgunner ★★★★★ ()
Ответ на: комментарий от vromanov

Потоки надо использовать тогда, когда нужно сделать что-то в background, и при этом хочется оставаться в одном адресном пространстве с «родителем» упрощается взаимодействие. НО! при этом очень желательно, чтобы background задача была как можно более отвязана от логики работы родительского приложения. GUI например. Выносить GUI в отдельный процесс - это может и кошерно, но геморройно.

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от tailgunner

И нет, я не о многоядерных системах, а о В/В.

что такое B/B я не понял.

В реальном мире однопроцессорные системы редкость.

Тут смотря что понимать под однопроцессорной системой. Я со своей колокольни вижу что в одном чипе типа AM3359 есть как основное ядро, так и ещё парочка мелких, которые для RT. Но! Эти ядра надо грузить кодом отдельно и код они выполняют отдельно, хотя и умеют ходить в адресное пространство всего процессора. т.е. это не назвать «процессами».

Dark_SavanT ★★★★★ ()
Последнее исправление: Dark_SavanT (всего исправлений: 1)
Ответ на: комментарий от Dark_SavanT

что такое B/B я не понял.

Ввод-вывод.

Эти ядра надо грузить кодом отдельно и код они выполняют отдельно

И их нужно ждать? Это процессоры. Параллельные.

tailgunner ★★★★★ ()
Ответ на: комментарий от vromanov

1) Не использовать потоки вообще

Ниасилил? Лох.

2) Если уж пришлось - использовать поцессы, а не потоки

Ниасилил? Лох.

anonymous ()
Ответ на: комментарий от Dark_SavanT

В современных реалиях вещь нечастая.

Да ну? В каждом втором DSP-проекте за последние пять лет они используются. Новый тренд, на. Есть даже компиляторы чистого Си в такие сети.

Pi-calculus насколько я понял применять кроме как полтора безумных учёных никто не умеет.

См. Occam - практичное воплощение пи-исчисления.

Message Passing - это хорошо, но накладные расходы в какой-то момент начинают быть заметны.

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

Только помним, что в реальном частном случае у нас потоки крутятся на одном ядре, что в итоге сводит все игрища с потоками (упрощённо) к переключению между кусками кода по прерыванию от таймера.

А для этого и хороши VM с зелеными потоками.

И тут надо задать себе вопрос - хочешь ли ты «псевдоодновременное исполнение» и нужно ли оно тебе, или ты можешь обойтись eventloop по «прерываниям»(epoll к примеру или таймеры).

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

anonymous ()
Ответ на: комментарий от tailgunner

И их нужно ждать? Это процессоры. Параллельные.

Да, процессоры. параллельные. Только это всё буржуйство, потому что есть AVR и Cortex M* в которых такой радости нет. Там пачка таймеров и периферии которую надо ждать, пока она флаг не выставит. «Параллельно» там может быть только прерывание, которое выкидывает тебя нафиг из текущего кода и перекидывает на обработчик.

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от Dark_SavanT

Тогда следует вспомнить, что параллельные процессы - эито не только способ эксплуатации аппаратного параллелизма, но и средство декомпозиции/абстракции.

tailgunner ★★★★★ ()
Ответ на: комментарий от anonymous

Да ну? В каждом втором DSP-проекте за последние пять лет они используются. Новый тренд, на. Есть даже компиляторы чистого Си в такие сети.

Я как-то до DSP не добирался, не доводилось. DSP это вообще отдельная тема, я про более «обычные» контроллеры и процессоры.

См. Occam - практичное воплощение пи-исчисления.

Okay, посмотрим.

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

А можно чутка поподробнее?

Нужно. Потому как тот же гуй иначе очень сложно (если вообще возможно) сделать отзывчивым, если нет истинной асинхронности.

Я собственно с этим и не спорю. Но кроме гуя люди городят ещё много чего на потоках, что можно было бы спокойно переложить на eventloop и не париться с тем, что тебя в самый неожиданный момент может кто-то прервать и попортить твои данные.

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от tailgunner

Возможно я неосилятор, но заводить процессы в софте я начну только очень хорошо подумав, ибо в большинстве случаев можно обойтись гораздо более простой абстракцией в виде eventloop. Анонимус выше об этом уже говорил.

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от Dark_SavanT

Анонимус говорил об Occam, в котором процесс был основной конструкцией языка, и зеленых нитях, которые делают создание процессов почти бесплатным.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

А зелёные нити это что в сути своей? Это маленький планировщик сидящий в процессе и про который ОС не знает(а про pthreads внезапно знает), который разруливает между собой множество кусков кода у которых контекста почти нет. Мне это в erlang и нравится, что тредов можно насоздавать очень много, а при том, что там шареных данных между процессами нет - нет и оверхэда на синхронизацию. кидаемся сообщениями и радуемся.

Но тут язык заточен под параллелизм и всё делается достаточно удобно. На сишечке, особенно под МК таким баловаться тоже конечно можно и иногда даже нужно, только вот всё равно получается такой из себя eventloop управляемый таймером и прилетающими прерываниями от периферии.

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от Dark_SavanT

А зелёные нити это что в сути своей?

Примерно это: http://en.wikipedia.org/wiki/Green_threads

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

«Планировщик» может быть настолько примитивным, что его и «планировщиком» называть неловко - так, переключатель стека.

под МК таким баловаться тоже конечно можно и иногда даже нужно, только вот всё равно получается такой из себя eventloop

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

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

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

Ага. Только вот городить процессы только чтобы были тоже идея не лучшая. Когда надо - обходимся FSM, когда получается сложно переходим к процессам.

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от vertexua

Пока по старому. Пробовали сделать револьвер - т.е. N очередей и они выбирается по кругу - получилось не очень.. Пока другим занимаемся

vromanov ★★ ()
Ответ на: комментарий от Dark_SavanT

Гуй как раз делается в основном потоке, а вот обработка в отдельном процессе. Чтобы она могла работать вообще без гуя

vromanov ★★ ()
Ответ на: комментарий от Dark_SavanT

Если стоит задача заюзать кучу ядер без процессов или потоков не обойтись

vromanov ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.