Попробуйте рассмотреть вариант с многопоточностью: взаимодействие между потоками организовать легче, чем между процессами.

msgsnd,msgctl,msgget,msgrcv

Плюнь на этот антиквариат, используй posix message queue. Событийная модель поддерживается.

Попробуйте рассмотреть вариант с многопоточностью: взаимодействие между потоками организовать легче, чем между процессами.

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

используй posix message queue

Спасибо, читаю.

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

Это как?

потоки только одним ядрышком обрабатываются.

Тут что-то не так. Реализация pthreads в юзерспейсе?

Нет, дело в том что исходная программа написана на python, совсем забыл что в C потоки сделаны по человечески. Видимо надо слезать с python пока мозг совсем не атрафировался =)

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

Плюс ко всему, событийная модель я так понял ограничивается вызовом mq_notify(), который позволяет процессу получать сигнал когда состояние очереди изменится с пустого на «содержит сообщение»(и то с некоторыми ньюансами).
Кроме того, я не нашол как заставить mq_recive() не удалять сообщение из очереди. Хотелось бы использовать паттерн Publish-Subscriber на межпроцессорном уровне, реализовать его поверх MQ, думаю, будет сложновато.

попробуй сразу взять MPI. в таком случае сможешь совершенно безболезненно масштабировать свое приложение на любое кол-во нод (мультипроцессор/мультикомпьютер).

Пожалуй это какраз то что мне нужно, буду изучать. Спасибо

Хотелось бы использовать паттерн Publish-Subscriber

Вам сюда, http://www.zeromq.org/.

что в C потоки сделаны по человечески

потоки не в С сделаны, потоки в ядре (ну или в юзерспейсе) :)

Взаимодействие между процессорами?

Может всё-таки межпроцессное?

Событийная модель там странная.

а чего тут думать

выбор то стандартен
если взаимодействие велико - нити + мутексы
если взаимодействие мало - то процессы + сокеты

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

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

все именно - крайне просто

есть данные - есть обработчики данных
есть взаимосвязь между потоками данных
и все - это разве сложно ?

тут главное помнить - что основополагающей чтукой здесь является то
что контент свитч достаточно дорог

1. Только для потоков (о чём нам shared memory говорит)
2. Можно
3. Про msgsnd и т.п. ничего сказать не могу, но очередь дело в принципе хорошее.

Если нужно быстрое взаимодействие, то лучше наверное потоки с ихней shared memory.

Кроме того нужно учесть что при росте кол. ва процессов очередь может стать узким местом.

А по мне так это может быть сложно. Параллельность - очень непростая штука.

ну это да - можно залезть в чудные дебри

Занимаясь оптимизацией вычислений на 4х ядерном процессоре

Нет, дело в том что исходная программа написана на python

Порвал шаблон.

MPI на 4 ядра? да Вы батенька знаток извращений.

В доках питона черным по белому написано:

CPython implementation detail: Due to the Global Interpreter Lock, in CPython only one thread can execute Python code at once (even though certain performance-oriented libraries might overcome this limitation). If you want your application to make better of use of the computational resources of multi-core machines, you are advised to use multiprocessing. However, threading is still an appropriate model if you want to run multiple I/O-bound tasks simultaneously.

http://docs.python.org/library/threading.html http://docs.python.org/library/multiprocessing.html

Видимо надо слезать с python пока мозг совсем не атрафировался =)

Плохому танцору.