LINUX.ORG.RU

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


0

0

Задача следующая: эмулируется среда передачи данных (радио эфир). Все процессы "подключенные" к среде должны иметь возможность передать данные всем остальным процессам. Ну и соответствеено все должны иметь возможность слушать (принимать данные). Причем желательно, чтобы слушающие были заблокированы на чем-нибудь, а не тупо крутились в цикле.

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

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

Идеи?

★★★★

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

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

Это почему?

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

tailgunner ★★★★★ ()
Ответ на: Re: Еще раз IPC: теперь более конкретно. от tailgunner

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

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

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

mv ★★★★★ ()
Ответ на: Re: Еще раз IPC: теперь более конкретно. от tailgunner

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

> Это почему?

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

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

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

alexru ★★★★ ()
Ответ на: Re: Еще раз IPC: теперь более конкретно. от alexru

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

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

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

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

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

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

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: Re: Еще раз IPC: теперь более конкретно. от tailgunner

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

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

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

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

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

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

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

alexru ★★★★ ()
Ответ на: Re: Еще раз IPC: теперь более конкретно. от alexru

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

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

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

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

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

tailgunner ★★★★★ ()

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

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

Macil ★★★★★ ()

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

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

fat-II ()

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

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

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

mv ★★★★★ ()

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

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


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

dimon555 ★★★★★ ()
Ответ на: Re: Еще раз IPC: теперь более конкретно. от dimon555

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

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

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