Russian Qt Forum
Ноябрь 23, 2024, 03:08 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: 1 [2]   Вниз
  Печать  
Автор Тема: QSharedMemory QReadWriteLock  (Прочитано 12627 раз)
vulko
Гость
« Ответ #15 : Ноябрь 06, 2014, 12:08 »

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

интересный подход к надежности...)))
Записан
ammaximus
Гость
« Ответ #16 : Ноябрь 06, 2014, 13:16 »

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

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

Я предлагал многопоточную реализацию, но у нас что-то присосались к этой системе и изменить это не выходит. Там нюанс в том, что любой процесс может находится на любой машине в пределах локальной сети и он общается с другими через сокет. Пока допилю это, потом будем искать лучшее решение.
Записан
vulko
Гость
« Ответ #17 : Ноябрь 06, 2014, 13:20 »

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

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

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

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

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

Сообщений: 11445


Просмотр профиля
« Ответ #18 : Ноябрь 06, 2014, 13:29 »

Я предлагал многопоточную реализацию, но у нас что-то присосались к этой системе и изменить это не выходит.
Не раз видел обратную ситуацию (хотят процессы вместо потоков). Процесс можно прибить, а вот поток нет
Записан
ammaximus
Гость
« Ответ #19 : Ноябрь 06, 2014, 18:13 »

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

Сообщений: 4350



Просмотр профиля
« Ответ #20 : Ноябрь 06, 2014, 18:42 »

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

И подход с процессами правильный, в дальнейшем вы много полезного сможете получить.
« Последнее редактирование: Ноябрь 06, 2014, 18:44 от Old » Записан
VPS
Гость
« Ответ #21 : Ноябрь 06, 2014, 20:11 »

Сегодня весь день убил на аналог вектора с форычем и еще не факт, что все правильно.
Вроде как библиотека Boost.Interprocess имеет свои реализации контейнеров для использования их в разделяемой памяти.
Записан
ammaximus
Гость
« Ответ #22 : Ноябрь 06, 2014, 23:36 »

Цитировать
И подход с процессами правильный, в дальнейшем вы много полезного сможете получить.
Спасибо, очень хотел услышать подобное))
Цитировать
Вроде как библиотека Boost.Interprocess имеет свои реализации контейнеров для использования их в разделяемой памяти.
Уже выбрана Qt, придется обойтись ее средствами. Но я подгляжу как там у них)
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #23 : Ноябрь 07, 2014, 11:04 »

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

Записан
Страниц: 1 [2]   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.053 секунд. Запросов: 22.