QSharedMemory QReadWriteLock

[vulko]

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

интересный подход к надежности...)))

[ammaximus]

интересный подход к надежности...)))

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

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

[vulko]

интересный подход к надежности...)))

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

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

ну если данных не так много, то можно и сокеты.

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

[Igors]

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

Не раз видел обратную ситуацию (хотят процессы вместо потоков). Процесс можно прибить, а вот поток нет

[ammaximus]

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

[Old]

и даже их медлительность при переключении для нас не критична.

Нет у них никакой медлительности.
В linux процессы переключаются с той же скоростью, что и потоки. Точнее потоки в linux, это те-же процессы, которые делят одно адресное пространство.

И подход с процессами правильный, в дальнейшем вы много полезного сможете получить.

[VPS]

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

Вроде как библиотека Boost.Interprocess имеет свои реализации контейнеров для использования их в разделяемой памяти.

[ammaximus]

И подход с процессами правильный, в дальнейшем вы много полезного сможете получить.

Спасибо, очень хотел услышать подобное))

Вроде как библиотека Boost.Interprocess имеет свои реализации контейнеров для использования их в разделяемой памяти.

Уже выбрана Qt, придется обойтись ее средствами. Но я подгляжу как там у них)

[Igors]

Меня лишь огорчает необходимость изобретать велосипеды. Сегодня весь день убил на аналог вектора с форычем и еще не факт, что все правильно.

А нужны ли такие хитрости? Можно держать в шаред простые массивы, напр "счетчик" и дальше следуют элементы. Что-то более сложное - сериализовать. При обращении к шаред прочитать данные (де-сериализовать), сразу же освободить шаред,  и потом, в "своей" памяти, спокойно разбираться. Если массив(ы) трудно зарезервировать по максимуму, то создавать для него новый (отдельный) шаред блок при перезаписи.