Страниц: [1]
  Печать  
Автор Тема: Параллельные запросы devctl к многопоточному менеджеру ресурсов  (Прочитано 951 раз)
Camarada
Full Member
***
Offline Offline

Сообщений: 222


Просмотр профиля
« : Сентября 07, 2016, 03:21:00 pm »

Упрощенно задача.

Есть менеджер ресурсов (RM), с прицепленным к нему адресом /dev/test
RM получает данные по определенному каналу, копит их в очереди и отдает клиенту по devctl, если данных нет обработчик devctl заблокируется и будет ждать.
Есть вторая команда devctl, там состояние (данные доступны всегда).
Как известно по умолчанию из-за того, что используется одна атрибутная запись, модель работать не будет.
Пока не появятся данные, первый devctl не разблокируется и будет держать атрибутную запись в локе.

Вариантов решения масса. Вопрос в том, какой выбрать.

1. Завести под получение данных отдельное имя (соответственно новую атрибутную запись)
2. Под каждое открытие создавать свою атрибутную запись (тогда обеспечим, что на каждый open будет свой канал без сторонних локов)
3. Похачить лок атрибутной записи, через mountpoint (там определяются функции лока)
4. Не блокироваться в обработчике, а возвращать _RESMGR_NOREPLY, делать отложенный ответ (наиболее трудоемко ИМХО).

Благодарен за мнения.
Записан
PoP
Sr. Member
****
Offline Offline

Сообщений: 336


Просмотр профиля
« Ответ #1 : Сентября 10, 2016, 02:48:32 pm »

Способ 4 вроде как самый "правильный". Разве что данные лучше забирать через read.
Два разных имени – тоже ничего, и данные и состояние можно забрать через read, это удобней на будущее, можно что то расширить не переписывая(пересобирая) старые клиенты. Но если несколько клиентов могут забрать одни и теже данные, всё равно нужен отложенный ответ.
Записан
Camarada
Full Member
***
Offline Offline

Сообщений: 222


Просмотр профиля
« Ответ #2 : Сентября 12, 2016, 09:04:41 am »

Способ 4 вроде как самый "правильный". Разве что данные лучше забирать через read.
Два разных имени – тоже ничего, и данные и состояние можно забрать через read, это удобней на будущее, можно что то расширить не переписывая(пересобирая) старые клиенты. Но если несколько клиентов могут забрать одни и теже данные, всё равно нужен отложенный ответ.
Мерси за ответ.

Кстати, нашел еще один способ на просторах openqnx. На мой вкус неплохой.
Перед тем, как встать на блокировку в очереди сделать iofunc_attr_unlock(), а потом забрать этот лок.

В в книжке с волшебником (Цирюлик. Анатомия параллелизма) описан способ именно с переопределением функции лочки ocb.
Записан
Страниц: [1]
  Печать  
 
Перейти в: