LINUX.ORG.RU

[IPC] Ограничения по времени


0

0

Стоит задача организовать межпроцессный обмен данных для их дальнейшей обработки. На время полной обработки (т.е. включая и перемещение данных) наложено достаточно жесткое ограничение по времени, поэтому нужно решение с минимальными издержками, причем кроссплатформенное (винда + линакс). Я смотрю в сторону FIFO на линаксе и пайпов на винде, придется делать некоторую обертку. У кого-нибудь есть практический опыт реализации подобного, кто что может посоветовать?

★★★★

Там кажись была какая-то разница в поведении при подключении клиентов у пайпу и фифе.

Вендовые пайпы имеют режим передачи сообщений (т.е. клиент читает ровно одну запись, а не сколько-там-байт-непрочитано). Аналогичное в линуксе - это сокеты AF_LOCAL с SOCK_SEQPACKET.

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

Особенно вендовые, которые AF_LOCAL не поддерживают. Действительно, пусть его прогоняет через весь TCP/IP стек, нам ведь не жалко? Под виндой лучше пайпы.

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

>>и много ты выиграешь, ifdef-ами обложась? а петля в любом случае практически одинаково работать будет

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

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от ananas

Да уж, «практически». У человека есть требования ко времени, если ты не заметил. И надо достичь максимума. В винде пайпы - родное и самое эффективное средство.

Pavval ★★★★★ ()
Ответ на: комментарий от MuZHiK-2

>А издержек лишних не будет между буферами гонять? Я просто еще смотрел на реализацию QLocalSocket - там в линаксе используется локальный сокет, на винде - пайпы.

Может оттуда и скомуниздь?

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

>>В винде пайпы - родное и самое эффективное средство.

Я в винде с пайпами не работал, но беглый обзор показывает, что оно сделано на основе smb. Это нормально?

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от Pavval

>>Может оттуда и скомуниздь?

Ну, все должно быть на С. Куте туда не впихнуть никак. Только если переработать этот класс на функции.

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

>Я в винде с пайпами не работал, но беглый обзор показывает, что оно сделано на основе smb.

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

Pavval ★★★★★ ()
Ответ на: комментарий от MuZHiK-2

Ну скомуниздь в смысле творчески переработай, но идеи реализации (какие-то тонкости) возьми.

Pavval ★★★★★ ()

нужно решение с минимальными издержками, причем кроссплатформенное (винда + линакс)

Разделяемая память?

Deleted ()
Ответ на: комментарий от Pavval

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

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

>требования по времени в неrealtime ос - хуйня собачья, и могут вычисляться очень приблизительно.

Да, но это не повод выбирать заведомо более медленный способ.

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

>>Разделяемая память?

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

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от Pavval

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

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

>>издержки зависят от сколько и какими порциями

Поток будет довольно плотный, порции (сообщения) будут редко больше 1Кб.

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

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

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

Сначала написать как удобно, потом запустить и воскликнуть «ой, *ля!» и начать переписывать как быстро. И да, у человека есть QLocalSocket как наглядный пример прозрачной работы с обоими интерфейсами, так что проблем с написанием не будет.

Pavval ★★★★★ ()
Ответ на: комментарий от MuZHiK-2

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

Затраты на синхронизацию потоков будут при любом механизме IPC. ИМХО в случае разделяемой памяти затраты как раз таки получаются минимальными.

Deleted ()
Ответ на: комментарий от Pavval

если использовать какие-то готовые обвязки - да, пофиг. но в начальных условиях их озвучено не было

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

>>Цифры озвучь.

Максимальное время между сообщениями - 10 мсек, но, скорее всего, оно будет меньше (но не чаще, чем 4 мсек). В среднем сообщение весит 1 Кб. Как-то так. За эти 4-10 мсек нужно успеть принять сообщение и обработать его, т.е. быть готовым к обработке следующего.

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от Deleted

>Затраты на синхронизацию потоков будут при любом механизме IPC.

Да.

ИМХО в случае разделяемой памяти затраты как раз таки получаются минимальными.


В свое время гонял на WinCE их message queues (аналог вендовых пайпов) и ручной вариант с SHM+семафоры. Получил практически равные скорости.

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

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

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

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от Pavval

В свое время гонял на WinCE их message queues (аналог вендовых пайпов) и ручной вариант с SHM+семафоры. Получил практически равные скорости.

Логично. Ведь по идее, где-то в недрах любого IPC - от fifo||pipe до tcp/ip на localhost - будет участок памяти, доступный и отправителю сообщения и получателю, плюс семафор, чтобы отправитель не подрался с получателем =).

Deleted ()
Ответ на: комментарий от MuZHiK-2

шлюз, как вариант. со своим кэшем, что добавляет +100 к надежности.

хотя говорю, как асутп-шник, последние 10 лет работающий на аэс, у меня могут быть другие приоритеты

ananas ★★★★★ ()
Ответ на: комментарий от MuZHiK-2

4мсек - это 250Гц. 1Кб*250Гц == 250Кбайт/с. О чем ты вообще, мужик? Это даже не детская цифра. Или у тебя встраиваемая железка с 20МГц процессором?

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

тут же, как я понял, поток данных внешний

Хм... Вроде наоборот - автору темы данные нужно гонять между локальными процессами. Иначе бы он на fifo и пайпы не смотрел.

Deleted ()
Ответ на: комментарий от ananas

> шареная память хороша для локальных процессов. тут же, как я понял, поток данных внешний

насколько я понял, здесь два процесса в пределах одной машины - вполне можно использовать и разделяемую память. Просто смысла никакого нет.

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

>>4мсек - это 250Гц. 1Кб*250Гц == 250Кбайт/с. О чем ты вообще, мужик? Это даже не детская цифра. Или у тебя встраиваемая железка с 20МГц процессором?

Вполне возможно, что все это будет крутиться на доблестных Эльбрусах (там порядка 500 МГц). Но вся проблема в том, что после получения данных идет достаточно затратная по ресурсам математическая обработка, тем более процессов будет порядка 5-6 и обработанные данные еще и между ними будут гоняться. Поэтому и нужно снизить издержки при обмене данными.

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от ananas

>>шареная память хороша для локальных процессов. тут же, как я понял, поток данных внешний

Обмен данными локальный.

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

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

Под вендой, да.

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

250Кбайт/сек - это просто не та цифра, которая создает хоть какие-нибудь проблемы.

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

>>Под вендой, да.

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

250Кбайт/сек - это просто не та цифра, которая создает хоть какие-нибудь проблемы.

То есть, в принципе, пофиг на чем написать IPC и издержки при любом способе будут примерно одинаковы?

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

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

ananas ★★★★★ ()
Ответ на: комментарий от MuZHiK-2

>За эти 4-10 мсек нужно успеть принять сообщение и обработать его, т.е. быть готовым к обработке следующего.

Если нужно ГАРАНТИРОВАНО успеть обработать за это время, то ИМХО без ОС реального времени никак не обойтись. Если нужно, чтоб в средне-интегральное укладывалось, то лучше через сокеты/пайпы, так-как решение с shared memory помимо хорошей производительности может дать ещё хорошую головную боль из-за плохой изоляции.

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

Сколько надо будет места под данные - неизвестно. Поэтому могут быть издержки на переаллокацию.

Надо думать, что пайп у тебя бесконечной длины... Сделай кольцевой буфер.

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

Нафиг они не нужны.

mv ★★★★★ ()
Ответ на: комментарий от MuZHiK-2

> То есть, в принципе, пофиг на чем написать IPC и издержки при любом способе будут примерно одинаковы?

На таких объемах - да.

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

>>Если нужно ГАРАНТИРОВАНО успеть обработать за это время, то ИМХО без ОС реального времени никак не обойтись.

Пытаемся выбить под это дело QNX, то у военных с такими вещами трудно, хотя 4.23 вроде как сертифицирована.

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

>>Если нужно ГАРАНТИРОВАНО успеть обработать за это время, то ИМХО без ОС реального времени никак не обойтись.

Пытаемся выбить под это дело QNX

Бгг. Если вы на Линуксе не выжмете времена порядка нескольких миллисекунд, QNX вам бесполезен %) Это не говоря о том, что QNX на Эльбрусе вряд ли запустится.

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

>> Если вы на Линуксе не выжмете времена порядка нескольких миллисекунд, QNX вам бесполезен %)

А можно подробнее.

Ядро 2.6 + PREEMPT обеспечивает время реакции в пределах 1мс при использовании планировщика реального времени.

Это не говоря о том, что можно использовать -rt.

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

>Ядро 2.6 + PREEMPT обеспечивает время реакции в пределах 1мс при >использовании планировщика реального времени.

Тут ты прав - _ядро_, а в остальном - реализация драйверов может покалечить все достижения ядра, без тестов на конкретном железе это все нановоздух :)

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