Межпроцессорный сигналинг

я передаю данные через МемориМаппедФайл*MMF (между 2я процессами), один процесс пишет, другой читает.
Если запустить параллельно, без доп защиты - происходит эффект "затирания" если считка и записи попадут в один и тот же момент.
Сейчас у меня транслируется:
1й байт - бул (флаг, идёт ли запись)
(некст)4 байта - длинна объекта(длинна массива)
(некйс)массив байт (объект)

С флагом в первом байте работает не "ах ти", тот же эффект затирания всё равно проявляется + подтормаживает.

Приложение "писатель", пишет из множества потоков в свои MMF объекты.

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

Какие варианты решения??

0

Fast shared Array, Buffer and Circular Buffer / Ring Buffer for .NET IPC with Memory Mapped Files пробовали?

1

Сообщение от DarkOrk один процесс пишет, другой читает. Какие варианты решения??

Почему не сделать просто обмен по TCP? На локальной машине это будет практически мгновенно.
Как бонус - возможность разнесения по разным машинам.

0

Сообщение от Storm23 Почему не сделать просто обмен по TCP? На локальной машине это будет практически мгновенно.

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

0

Сообщение от Убежденный Намного медленнее, чем через разделямую память. По крайней мере, в Windows. К тому же для TCP нужен отдельный порт, который гарантированно свободен. IMHO, TCP для межпроцессного обмена в рамках одной машины как-то не очень.

Ну я предлагаю просто как вариант.
Касаемо порта - да порт нужен. Но и для файла фиксированное имя тоже нужно, что тоже не очень.
Касаемо скорости - я конечно специально не мерял, но не очень понимаю с чего бы оно могло тормозить. Ведь на локалхосте пакеты даже через сетевую карту не идут, только через драйвер сети. То есть весь процесс обмена идет только через память, что не сильно отличается от MMF.
Зато есть очевидные плюсы:
1) Готовая инфраструктура сигналинга. Асинхронный сокет выдает событие о приходе данных. Никаких бесконечных циклов проверки, никаких коллизий записи/чтения, никаких "флаг, идёт ли запись". Данные от отправителя напрямую приходят к получателю.
2) Да, свободный порт нужен. На зато мы получаем автоматически запрет на запуск второго экземпляра приложения(которое не запустится, потому что порт будет занят). В случае MMF - что произойдет если будет запущен второй экземпляр "писателя"?
3) Сокеты - это full-duplex. MMF - в общем случае нет (если файл - один).
4) Масштабируемость, о чем я уже писал.

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

0

Сообщение от Storm23 Касаемо порта - да порт нужен. Но и для файла фиксированное имя тоже нужно, что тоже не очень.

Для MMF можно сгенерировать имя типа "Global\\{xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}",
которое имеет все шансы быть достаточно уникальным. А вот найти свободный порт,
который гарантированно никем не будет занят - это проблема посложнее.

Сообщение от Storm23 Касаемо скорости - я конечно специально не мерял, но не очень понимаю с чего бы оно могло тормозить. Ведь на локалхосте пакеты даже через сетевую карту не идут, только через драйвер сети. То есть весь процесс обмена идет только через память, что не сильно отличается от MMF.

В Windows любые сокетные операции на localhost проходят, как минимум, через стек WinSock-
провайдеров, потом переключение в ядро, потом через верх стека TCP/IP (afd.sys/tcpip.sys),
там они могут еще фильтроваться антивирусами/фаерволами, иногда в отложенном режиме.
В итоге может вылиться в тысячи тактов. А когда обмен идет через MMF, то даже
системных вызовов нет, просто чтение и запись в память. Т.е. суммарный перфоманс
может различаться на порядки.

Сообщение от Storm23 1) Готовая инфраструктура сигналинга. Асинхронный сокет выдает событие о приходе данных. Никаких бесконечных циклов проверки, никаких коллизий записи/чтения, никаких "флаг, идёт ли запись". Данные от отправителя напрямую приходят к получателю.

Да, согласен. Вообще, MMF в сравнении с сокетами или пайпами - это разные модели
передачи данных. У MMF нет сигналинга "из коробки".

Сообщение от Storm23 2) Да, свободный порт нужен. На зато мы получаем автоматически запрет на запуск второго экземпляра приложения(которое не запустится, потому что порт будет занят). В случае MMF - что произойдет если будет запущен второй экземпляр "писателя"?

Ничего страшного не произойдет, CreateFileMapping вернет успех, но в last error
будет записано ERROR_ALREADY_EXISTS. Т.е. можно ограничить запуск второго писателя,
если нужно.

Сообщение от Storm23 3) Сокеты - это full-duplex. MMF - в общем случае нет (если файл - один).

Ну почему же?
В MMF можно писать и читать в оба конца одновременно.
Другое дело - как это все синхронить и разруливать.

Сообщение от Storm23 4) Масштабируемость, о чем я уже писал.

Это да. Если нужно, к примеру, обмениваться данными в локальной сети, то
вряд ли есть что-то лучше, чем сокеты или пайпы (или RPC поверх них).

Сообщение от Storm23 В общем, в определенных случаях такой вариант не так уж и плох. Я так делал в некоторых проектах, работало нормально.

В определенных случаях - безусловно. Но далеко не всегда и не везде.
Просто TCP и сокеты довольно часто советуют для IPC, хотя, на мой взгляд,
требование свободного порта и long path - довольно существенные недостатки
данного способа, чтобы ими пренебрегать.

1

Чем не устраивает WCF PIPE? Кажется именно для этих задач пайпы и были придуманы?

0

Сообщение от Storm23 Почему не сделать просто обмен по TCP?

Тогда уж именованные каналы, это еще быстрее.

0

Сообщение от DarkOrk Какие варианты решения??

Пойдёт? https://gorillacoding.wordpres... unication/

0