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

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

Russian Qt Forum > Forum > Qt > Общие вопросы > технология работы с QSharedMemory
Страниц: [1]   Вниз
« предыдущая тема следующая тема »
  Печать  
Автор Тема: технология работы с QSharedMemory  (Прочитано 8325 раз)
ilyagoo
Гость
« : Декабрь 15, 2010, 12:38 »
есть два процесса.
один кладет в общую память большой объем данных, второй выбирает из них некоторый нужный ему кусок для обработки.
при этом второй должен дать первому команду начать и перестать класть данные, ну и прочее управление.
каким образом было бы логичнее осуществлять управление, через сокеты, каналы и т.п. или же передавать события через общую память?
что выгоднее и проще?

спасибо.
Записан
lex_newton
Гость
« Ответ #1 : Декабрь 15, 2010, 14:02 »
Сложно сказать, что выгоднее. Не до конца ясна задача и частота обращения read\write. Возможно, вам подойдет как signal\slot так и другие механизмы. нужно подробно смотреть.
Записан
ilyagoo
Гость
« Ответ #2 : Декабрь 15, 2010, 14:13 »
Цитировать
Возможно, вам подойдет как signal\slot
нет, разные процессы.

задача - увести большой объем информации из некоего подобия драйвера для ее обработки.
запись в данный момент ориентировочно 60 раз в секунду по 131027 байта. в недалеком будущем трафик может быть равен 120 Мб/с пачками побольше.
пишуший процесс нежелательно блокировать чтением в другом процессе.
Записан
lex_newton
Гость
« Ответ #3 : Декабрь 15, 2010, 14:47 »
Хм.. значит, у нас есть один процесс который производит чтение данных в очередь(условно назовем так структуру данных).

Какова дальнейшая судьба этой очереди? она записывается в файл? или же удаляется после того, как другой процесс считал и обработал эти данные? Какова природа данных и в какой структуре данных она должна храниться? что с ней происходит в дальнейшем?
Записан
ilyagoo
Гость
« Ответ #4 : Декабрь 15, 2010, 15:13 »
для простоты картины назовем эту очередь циклическим буфером))
есть два варианта работы:
1) процесс-обработчик (ПО) попросил некоторые данные и дал команду процессу-драйверу (ПД) их класть в буфер. ПО знает необходимое ему количество и может остановить драйвер когда его (кол-во) получит. тут возможны варианты управления:
    - ПО может сказать ПД это количестно и ПД остановится сам
    - ПО может проверять кол-во данных в буфере и дать команду остановки ПД
после обработки данные становятся ненужными.

2) ПО просит ПД начать трансляцию данных потоком, при этом ПО волен выбрать некоторый кусок потока и обработать его. в произвольный момент времени ПО может остановить ПД.
Записан
lex_newton
Гость
« Ответ #5 : Декабрь 15, 2010, 15:46 »
Ага. теперь стало намного понятней Подмигивающий
На самом деле - я не совсем понимаю зачем QSharedMemory. Возможно, есть смысл передавать данные сразу через что-нибудь вроде pipe. Тогда можно будет избежать необходимости синхронизации(в связи с которой будет остановка потока производящего запись в буфер) и избежать затирания данных в кольцевом буфере, в случае переполнения.
Насчет управления этим процессом - можно воспользоваться такой штукой: QRemoveSignal ( http://qt-apps.org/content/show.php/QRemoteSignal?content=112061 ). или же через каналы(самый простой и понятный вариант)
Если все же shared memory небходимо, то без блокировки на время чтения\записи - никуда не деться. или шаманить алгоритм препятствующий возникновению коллизий Подмигивающий
Записан
ilyagoo
Гость
« Ответ #6 : Декабрь 15, 2010, 16:33 »
был вариант обмена через сокеты, но то ли я что-то сделал не лучшим образом, то ли у них есть некий предел, но мне удалось прокачать чуть больше 60 Мб/с на локальной машине. есть ли предел скорости и размера буфера у канала? у сокета? имеется в виду pipe винды?
Записан
lex_newton
Гость
« Ответ #7 : Декабрь 15, 2010, 17:53 »
Если честно - на таких скоростях я не тестировал... даж не знаю какую технологию предложить
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #8 : Декабрь 15, 2010, 18:22 »
Я делал такое на shared memory + семафоры между процессами (тоже нужна была скорость). ничего страшного нет
Записан
ilyagoo
Гость
« Ответ #9 : Декабрь 15, 2010, 22:07 »
я и не боюсь))
вопрос в том, как этим управлять.
и еще вдруг кто-нибудь оценивал производительность сокетов и пайпов...
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #10 : Декабрь 15, 2010, 22:25 »
Цитата: ilyagoo от Декабрь 15, 2010,  22:07
я и не боюсь))
вопрос в том, как этим управлять.
и еще вдруг кто-нибудь оценивал производительность сокетов и пайпов...
Ну быстрее чем через shared memory - точно не будет  Улыбающийся
Управлять просто: 2 семафора, сигналите по одному и ждете на другом. Для др. процесса аналогично - просто семафоры меняются местами. Это максимально упрощенно/примитивно, но часто больше и не требуется
Записан
Страниц: [1]   Вверх
  Печать  
« предыдущая тема следующая тема »
 
Перейти в:  


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