Страниц: [1]
  Печать  
Автор Тема: блокирование потоков ресурс-менеджера  (Прочитано 4244 раз)
Ivan
Участник
*
Offline Offline

Сообщений: 23


Просмотр профиля
« : Марта 14, 2004, 06:52:17 pm »

К сожалению не нашел ответ на этот вопрос ни в документации, ни в форуме. А именно как блокировать клиентов, если resmgr не справляется с запросами.
Решение, предлагаемое QSS для блокировки клиента - это
1) запомнить ctp->rcvid;
2) выйти из обработчика c _RESMGR_NOREPLY;
3) выполнить позже MsgReply по запомненному rcvid
В /usr/src/*/input/src/hardware/devi/resmgr.c приведен пример, где при обработки IO_READ динамически формируется очередь из блокированных клиентов. Вопрос кашерности динамического исползования памяти в драйвере не столь однозначен. Не всякий драйвер по причинам быстродействия и отказоустойчивости системы вцелом может себе это позволить. Ну допустим очередь будет строиться в заранее выделенном пуле. Но опять же, следует тогда хотя бы иметь представление о приоритетах клиентов и строить очередь исходя из приоритетов. Т.е. выполнять работу которую можно свалить на систему путем блокирования потока, например, pthread_cond_wait(). При окончании обслуживания одного клиента вызовем pthread_cond_signal() и заставим работать систему. Использование отдельного потока и его блокирование можно увидеть во многих клиент-серверных взаимодействиях *NIX. Согласен, что в QNX есть другой, может даже более гибкий механизм, но про блокирование потока-обработчика целиком ни слова. Сам попробывал такой вариант, но не все работает: происходит блокирование остальных обработчиков на CONDVAR и как я понял не моей, а библиотечной. Хотя сам честно вызываю iofunc_attr_unblock перед pthread_cond_wait. Пока что предпологаю, что проблемы не со стратегией, а с реализацией. Но все же может я не все допонимаю в взаимодействиях внутри ресурс-менеджера.
Прошу высказать ваши мнения по данному вопросу.
Записан
MikeP
Участник
*
Offline Offline

Сообщений: 6


Просмотр профиля WWW
« Ответ #1 : Марта 15, 2004, 09:35:21 am »

Здесь только Кертен...
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #2 : Марта 15, 2004, 12:01:03 pm »

А именно как блокировать клиентов, если resmgr не справляется с запросами.

А зачем так сильно мудрить?
Чем вас не устраивает типовой многопотоковый менеджер, пусть с соответствующе большими значениями верхней ватерлинии пула...:
- каждый поток будет наследовать приоритет запросившего обслуживание клинента;
- низкоприоритетные клиенты будут ожидать обслуживания при... "не справляется с запросами";
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #3 : Марта 15, 2004, 05:27:38 pm »

А если уж совсем невмоготу самому обрабатывать очерёдность клиентских запросов:

1. посмотрите статью:
http://qnxclub.net/files/articles/serv_nblock/serv_nblock.html
- это всё для TCP/IP socket - но может на что натолкнёт.

2. MsgDeliveryEvent() - может и переврал название, пишу по памяти - но это как раз то, что нужно - IMHO - у Кёртена, кстати, ему уделено достаточно внимания.
Записан
Ivan
Участник
*
Offline Offline

Сообщений: 23


Просмотр профиля
« Ответ #4 : Марта 16, 2004, 11:44:50 pm »


Olej:
А зачем так сильно мудрить?

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

thread n
..........
  pthread_mutex_lock ( &mutex )
  while( busy_ports_count == ports_count )
    pthread_cond_wait ( &convar, &mutex );
  pthread_mutex_ulock ( &mutex )
..........


thread m
..........
  port_free ();
  pthread_cond_signal ( &condvar )
..........

  Затык возник с атрибутной записью, она остается залоченной. Вот если перед pthread_cond_wait вызвать iofunc_attr_unlock (), а после iofunc_attr_lock () работает сносно, но не всегда. Как я понял iofunc_attr_lock влияет на разные примитивы синхронизации в зависимости от обрабатываемого сообщения ( rlocks, wlocks ). Так как инфы по этому достаточно не накопал, только домыслы по несовсем убедительным тестам, пока отказался от этой идеи: отвечаю с _RESMGR_NOREPLY, храню rcvid по приоритетам, и отвечаю ему врукопашную.
Записан
ed1k
QOR.Moderator
*****
Offline Offline

Сообщений: 739


Просмотр профиля WWW
« Ответ #5 : Марта 17, 2004, 04:15:48 am »

Ivan
Допустим имется железяка, у ней несколько буферов. Блокировать атрибутную запись целиком, что бы работал типовой многопотоковый менеджер нерационально.

А все же можно, хоть например, что за железяка. Трудно себе могу представить... однако. Имеете ли вы ввиду, что пока один клиент пишет в один буфер, другой клиент может преспокойно писать в другой буффер, и в результате железяка со всем этим разгребется и результат будет такой же (или даже лучше), как если бы оба один за другим писали в один буфер? Если так, то делайте несколько имен в РМ (по количеству буферов) и соответсвенно несколько атрибутных записей, а клиенты пусть select()-ом находят свободный дескриптор. Пусть у клиента голова болит что делать, если свободных дескрипторов нет. Мне кажется так красивее и проще Если "несколько" это довольно много или переменное число (разные имена для различный типов железки), то организуйте их в директорию, чтобы клиент мог открыть все файлы /dev/mydevice/*
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #6 : Марта 17, 2004, 11:22:18 am »

Мне кажется так красивее и проще

Именно так.

Вообще, к первичному вопросу:
- в OS вам дан некоторый механизм, который имеет некоторую модель использования, которая, кстати, отрабатывалась ещё в недрах 4.Х, т.е. лет 5-10...
- теперь вам это "непрозрачно", и хотелось бы сделать нечто, что: а).было бы совершенно подконтрольно (своими руками написано!) б).делало бы что-то сверх (помимо) модели, предоставленной OS;
- такая ситуация "придумывания" чаще всего возникает не от реальной потребности, а от нежелания долго и тщательно разбираться с нюансами логики исходной модели...
- ... а ещё из-за излишнего доверия к тому, что если своими руками прописано - то оно получше будет...

Но в таком случае - вам практически мало нужны механизмы OS, тогда не проще ли использовать минимальное RT ядро типа RTEMS ... или просто писать для "голого" железа - понятно, легко, доступно, полностью подконтрольно .
Записан
Ivan
Участник
*
Offline Offline

Сообщений: 23


Просмотр профиля
« Ответ #7 : Марта 17, 2004, 11:29:34 pm »

Железяка куётся моими коллегами. Идея разрезать ресурс на несколько у меня была, но как то не сложилась. А использование select - действительно красивое решение. Если конечный вариант железа будет как данный эскиз попробую ваше предложение. Спасибо.
Записан
Страниц: [1]
  Печать  
 
Перейти в: