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

Вот что я смог придумать:

Многопроцессорный(1) и однопроцессный, многопоточный(2):

• Влияние ошибок сегментации: в (2), если один модуль вызывает ошибку сегментации, происходит сбой всего приложения. В (1) модули имеют разные области памяти, и, таким образом, произойдет сбой только модуля, вызвавшего ошибку сегментации.
• Гарантия доставки сообщения. В (2) вы можете предположить, что доставка сообщения гарантирована. В (1) принимающий модуль может дать сбой перед получением или во время обработки сообщения.
• Совместное использование памяти между модулями. В (2) вся память совместно используется всеми модулями, поэтому вы можете напрямую отправлять объекты сообщений. В (1) вам необходимо использовать «общую память» между модулями.
• Реализация обмена сообщениями: в (2) вы можете отправлять объекты сообщений между модулями, в (1) вам нужно использовать любой из сетевых сокетов, сокет unix, каналы или объекты сообщений, хранящиеся в общей памяти. С точки зрения эффективности хранение объектов сообщений в общей памяти кажется лучшим выбором.
• Использование указателя между модулями. В (2) вы можете использовать указатели в своих объектах сообщений. Право собственности на объекты кучи (доступ к которым осуществляется с помощью указателей в сообщениях) может быть передано принимающему модулю. В (1) вам необходимо вручную управлять памятью (с помощью пользовательских функций malloc/free) в области «Общая память».
• Управление модулями. В (2) вы управляете только одним процессом. В (1) вам необходимо управлять пулом процессов, каждый из которых представляет один модуль.

Похоже, вы реализуете коммуникативные последовательные процессы. Превосходно!

Прежде всего, рассматривая потоки и процессы, я бы придерживался потоков; время переключения контекста быстрее (особенно в Windows, где переключение контекста процесса происходит довольно медленно).

Во-вторых, разделяемая память и очередь сообщений; если вы выполняете полную синхронную передачу сообщений, это не повлияет на производительность. Подход с общей памятью включает в себя общий буфер, который копируется отправителем и копируется читателем. Это тот же объем работы, который требуется для очереди сообщений. Поэтому для простоты я бы придерживался очереди сообщений.

на самом деле вы могли бы рассмотреть возможность использования канала вместо очереди сообщений. Вы должны написать код, чтобы сделать канал синхронным (обычно они асинхронны, что было бы моделью акторов; очереди сообщений часто могут быть установлены на нулевую длину, что делает то, что вы хотите, чтобы он был синхронным и правильно CSP), но тогда вы может так же легко использовать сокет вместо этого. Затем ваша программа может стать распределенной на несколько машин, если возникнет такая необходимость, но вам вообще не нужно менять архитектуру. Также именованные каналы между процессами являются эквивалентным вариантом, поэтому на платформах, где время переключения контекста процесса хорошее (например, Linux), вопрос о потоке и процессе отпадает. Таким образом, работая немного усерднее, чтобы использовать канал, вы получаете очень значительные возможности масштабирования.

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

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

Между прочим, в Windows такие вещи очень сложно реализовать. В любом языке Microsoft просто нет надлежащего эквивалента select(). Для сокетов есть select(), но вы не можете использовать его для конвейеров и т. д., как в Unix. У ребят из Cygwin были серьезные проблемы с реализацией их версии select(). Я думаю, что они закончили с потоком опроса для каждого файлового дескриптора; массово неэффективно.

Удачи!

В вашем вопросе отсутствует описание того, как реализованы «модули» и что они делают, и, возможно, описание среды, в которой вы планируете все это реализовать.

Например:

• Если к самим модулям предъявляются некоторые требования, которые затрудняют их реализацию в виде потоков (например, они используют сторонние библиотеки, не поддерживающие потоки, имеют глобальные переменные и т. д.), ваша система доставки сообщений также не может быть реализована с помощью потоков.
• Если вы используете такую ​​среду, как Python, которая не очень хорошо обрабатывает параллелизм потоков (из-за его глобальной блокировки интерпретатора) и работаете в Linux, вы не получите никаких преимуществ производительности с потоками по сравнению с процессами.

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

tl;dr: вы только поцарапали поверхность своим вопросом :)