QNX/UNIX: Анатомия параллелизма

 iofunc_funcs_t ownocb_funcs = {
  _IOFUNC_NFUNCS, ownocb_calloc, ownocb_free
 };
 iofunc_mount_t mountpoint = { 0, 0, 0, 0, &ownocb_funcs };

( _IOFUNC_NFUNCS— это просто константа, определяющая число функций и равная 2.)

• Определяем собственные функции размещения и уничтожения структуры OCB с прототипами:

 IOFUNC_OCB_T* ownocb_calloc(resmgr_context_t*, IOFUNC_ATTR_T*);
 void ownocb_free(IOFUNC_OCB_T *o);

В нашем случае это: а) интерфейс из C-понятия «создать-удалить», в C++ — «конструктор-деструктор» и б) именно здесь создается и инициализируется сколь угодно сложная структура экземпляра OCB.

• В функциях обработки запросов клиента (операций менеджера) мы позже будем в качестве 3-го параметра вызова обработчика получать указатель именно того экземпляра, для которого требуется выполнить операцию, например:

 int read(resmgr_context_t*, io_read_t*, IOFUNC_OCB_T*) {...}

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

• В таблице операций ввода/вывода переназначаем функцию-обработчик операции блокирования атрибутной записи:

 io_funcs.lock_ocb = nolock;

• В качестве такого обработчика предлагаем «пустую» операцию:

 static int nolock(resmgr_context_t*, void*, IOFUNC_OCB_T*) {
  return EOK;
 }

Запустим менеджер и проверим, как происходит его установка в системе:

 /dev # ls -l /dev/w*
 nrw-rw-rw- 1 root root 0 Nov 09 23:17 /dev/wmng

Теперь подготовим простейший клиент:

 void main(int argc, char *argv[]) {
  char sResName[_POSIX_PATH_MAX + 1] = "/dev/wmng";
  if (argc > 1) strcpy(sResName, argv[1]);
  int df = open(sResName, O_RDWR | O_NONBLOCK);
  if (df < 0)
  perror("device open"), exit(EXIT_FAILURE);
  cout << open << sResName
  << " , desc. = " << df << endl;
  char ibuf[2048], obuf[2048];
  int r, w;
  while (true) {
  if ((r = read(df, obuf, sizeof(obuf))) < 0) break;
  cout << '#' << obuf << endl; cout << '>' << flush;
  cin >> ibuf;
  if (( w = write(df, ibuf, strlen(ibuf) + 1)) <= 0) break;
  }
  if (r < 0) perror("read error");
  if (w <= 0) perror("write error");
  exit(EXIT_FAILURE);
 }

Запустим одновременно 2 экземпляра клиента (их, собственно, может быть сколь угодно много) и убедимся, что каждый из клиентов работает со своей отдельной копией структур данных внутри процесса менеджера ресурса:

 # wmclient
 open /dev/wmng , desc. = 3 #
 >1234
 #1234
 >54321
 #54321
 >
 # wmclient
 open /dev/wmng , desc. = 3
 #
 >qwerty
 #qwerty
 >asdf
 #asdf >

Отчетливо видно, что каждый клиент с получением своего файлового дескриптора (реально это дескриптор соединения) получает и свой экземпляр данных.

Полную параллельность и независимость обращений (например, возможность выполнения read в то время, когда менеджер занят выполнением read от другого клиента) к данному псевдоустройству отследить сложнее. Для этого в код обработчиков операций чтения/записи следует внести ощутимую задержку (например, sleep или delay) и воздействовать достаточно плотным потоком запросов со стороны нескольких клиентов. Такие эксперименты показывают полную независимость операций по разным файловым дескрипторам, что обеспечивается переопределением обработчика по умолчанию — iofunc_lock_ocb_default.

Сообщения или менеджер?

Этот вопрос возникает (должен возникать!) у каждого, кто приступает к разработке реального проекта, особенно если функциональность проекта распределяется между несколькими автономными процессами. Такая структуризация и вовсе не привычна разработчикам, приходящим из мира Windows. Для UNIX создание проектов, в которых порождается несколько процессов, такая структуризация уже гораздо органичнее, но и там это чаще всего лишь клонирование образа единого серверного процесса посредством fork. QNX предоставляет возможность идти еще дальше в построении приложений, представленных (разделенных) как группа разнородных взаимодействующих процессов:

• Уже полученные нами ранее тестовые результаты времени диспетчеризации и переключений контекстов (пусть даже они и сделаны бегло, только в качестве оценочных ориентиров) показывают, что представления приложения в качестве единого, монолитного процесса или процесса, содержащего группу потоков, либо просто разбиение приложения на группу процессов по производительности если и не эквивалентны, то крайне близки. Этот фактор не должен быть определяющим, и при структурировании приложения следует руководствоваться целесообразностью и удобством.

• Процессы QNX сохраняют все качества таковых и в UNIX вообще: они являются изолированными сущностями, которые взаимодействуют, если это необходимо, используя достаточно тяжеловесные (расточительные) механизмы IPC. Собственно, в этом и ценность процессов с их изолированными адресными пространствами — это механизм обеспечения высокой надежности и живучести приложений. Но QNX, не сужая спектр общепринятых IPC-механизмов, привносит совершенно новый «слой» инструментария взаимодействия — обмен сообщениями микроядра. При этом «проницаемость» процессов как отдельных клеток живого организма становится много выше, нисколько не снижая их «защищенности».