Еще раз IPC: теперь более конкретно.

> подходит разделяемая память, но при работе только с ней не возможна блокировка ожидающих процессов.

Это почему?

В порядке бреда: мультикастинг на lo.

> В порядке бреда: мультикастинг на lo.

У дураков мысли сходятся/умные мыслят одинаково. Но я потом подумал, что это не очень быстро будет.

> Это почему?

А на чем блокироваться? Только на каком-нибудь другом объекте синхронизации, находящемся в той-же памяти. При этом разбудить сразу всех похоже возможно только условными переменными, но чего-то с ними не все ясно + требуют наличие еще mutex-a.

> В порядке бреда: мультикастинг на lo.

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

> А на чем блокироваться? Только на каком-нибудь другом объекте синхронизации, находящемся в той-же памяти.

И что такого? SysV IPC используй, если не доверяешь себе :)

> При этом разбудить сразу всех похоже возможно только условными переменными, но чего-то с ними не все ясно + требуют наличие еще mutex-a.

Да ну, фигня. Хоть сигналом их буди, хоть сообщением в message queue.

>> В порядке бреда: мультикастинг на lo.

> Скорее всего выигрыша в производительности не будет по сравнению с тем, что есть.

Будет. Если бы у тебя были не TCP-сокеты, а Unix - тогда наверное выигрыша бы не было.

> А так хоть плюс - часть потоков можно на других машинах запускать.

Ну ты разберись, что тебе надо - кластер или отсутствие накладных расходов.

> Да ну, фигня. Хоть сигналом их буди, хоть сообщением в message queue.

Для сигнала нужно pid знать, а message queue если несколько потоков читают, то просыпается только один (причем при появлении последующих сообщений в очереди они все просыпаются по кругу. Какая-то странная логика там реализована :) ).

> Будет. Если бы у тебя были не TCP-сокеты, а Unix - тогда наверное выигрыша бы не было.

Да, была мысль сначала попробовать unix sockets. Наверное с этого и начну.

> Ну ты разберись, что тебе надо - кластер или отсутствие накладных расходов.

В первую очередь производительность. Но бонусы приветствуются :)

> Для сигнала нужно pid знать

И в чем проблема выделить кусок разделяемой памяти под массив pid? Тебе всё равно придется реализовывать какую-то процедуру знакомства/присоединения.

> В первую очередь производительность.

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

Попробуй в разделяемой памяти организовать что-то типа лога/очереди. Типа процесс писатель просто добавляет сообщение в конец лога. Процессы-читатели делают все возможное, чтобы прочитать лог до конца. Если кто-то не успел прочитать, пока лог не начал переполняться, значит случилось что-то страшное и процесс тихо-мирно сдыхает с позору. Короче а-ля STM.

Ну, разве шо UDP попробовать. Если а одной машине всё крутится, надёжность доставки, думаю, и так будет на уровне...

Пусть у каждого процесса будет свой кусок shared memory. Все процессы ммапят себе shm других процессов. В shm будут queue или lockless ring buffer [1] плюс флажок-futex о наличии новых данных. Пишущий процесс добавляет всем в queue/ringbuffer свои данные, поднимает флажок и забывает про них. Процессы-читатели висят на futex'ах, по срабатыванию оного вычитывают все данные.

1. Можно сделать по образцу: http://article.gmane.org/gmane.linux.kernel/849412

>эмулируется среда передачи данных (радио эфир)
>Сейчас все это организовано как TCP-сервер

а это точно адекватная модель? может какой средой иммитационного моделирования воспользоваться или чего на основе теории массового обслуживания?

Достаточно адекватная, если быстро распространять данные всем процессам. Эфир моделируется для приложения у которого желательно менять только 2 функции: ожидание пакета и отправка пакета. Насколько я знаю никакие средства не позволяют проводить моделирование не внося изменений в код программы.