LINUX.ORG.RU

Межпроцессорное взаимодействие, event-driven?


0

1

Доброго времени суток господа лоровцы!
Занимаясь оптимизацией вычислений на 4х ядерном процессоре, невольно начинаешь задумываться, а как бы использовать все ядрышки по максимуму. Но сдесь есть множество сложностей, первой из них безусловно является необходимость реализации межпроцессорного взаимодействия(т.к. у каждого процесса будет своя память, а задание общее). Задавшись таким вопросом, я полез читать документацию, и конечно-же обнаружил множество способов как переписать свою программу, для работы с несколькими ядрами:
1. Общение через общую память(shared memory)
2. Общение через сокеты(или пайпы, которые в использовании мало чем отличаются)
3. Создание очереди сообщений (системные вызовы msgsnd,msgctl,msgget,msgrcv в linux), если я правильно понял man'ы.
Мне доводилось использовать только пункты 1 и 2. Я не совсем понимаю как использовать 3. И кроме того, нет ли в linux, или в любом другом хорошем месте, реализаций событийно-ориентированного взаимодействия между процессами? То есть именно на уровне ядра, а не обёртки для конкретного языка над вышеперечисленными возможностями.
Может быть я конечно глупости говорю, в таком случае поправьте меня пожалуйста. Спасибо за помощь!


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

Sorcerer ★★★★★
()

msgsnd,msgctl,msgget,msgrcv

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

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

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

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

nach
() автор топика
Ответ на: комментарий от AptGet

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

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

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

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

Это как?

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

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

nach
() автор топика
Ответ на: комментарий от AptGet

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

nach
() автор топика
Ответ на: комментарий от AptGet

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

nach
() автор топика

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

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

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

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

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

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

Harald ★★★★★
()

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

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

Olegymous ★★★
()

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

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

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

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

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

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

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

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

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

ae1234 ★★
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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