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

fabers

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

Стивенс в помощь. Ну и man pthreads.

Ты еще man futex предложи

Ябпочитал.

http://research.microsoft.com/en-us/um/people/simonpj/papers/stm/

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

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

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

man FSM. Потоки тебе тогда ещё долго не понадобятся.

https://en.wikipedia.org/wiki/Pi_calculus

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

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

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

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

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

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

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

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

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

Поддержу. 1) Не использовать потоки вообще 2) Если уж пришлось - использовать поцессы, а не потоки

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

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

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

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

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

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

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

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

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

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

Как очередь в итоге сделали?

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

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

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

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

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

Ввод-вывод.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мне когда-то в похожей теме посоветовали эту книгу.

http://www.books.ru/books/qnxunix-anatomiya-parallelizma-fail-pdf-549199/?sho...

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

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

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

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

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

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

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

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

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

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

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

Благодарю.

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

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

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