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

Суть вопроса в следующем. Писать менеджер ресурсов как системный драйвер некоторого специфического аппаратного устройства — это удел единиц (на каждое устройство — по одному разработчику! … шутка), но менеджер ресурсов — это прекрасная альтернатива для описания чисто программных «псевдоустройств». Например, это могла бы быть некоторая оконная GUI-подсистема, в которой openсоздает прорисовку окна на экране, writeвписывает некоторый текст в окно, a readсчитывает из окна текст, вводимый пользователем (подобная конструкция описывалась нами в главе «Драйверы» [4]). Таким решением мы с минимальными затратами придаем POSIX-функциональность своим совершенно неожиданным программным подсистемам.

Однако для «истинных драйверов» запросы open— read— write: должны, как правило, быть последовательными (право, бессмысленно пытаться писать и читать один файл одновременно из двух потоков)… Это обусловливается тем, что в конечном итоге все функции-обработчики операций менеджера ресурса выходят на единичный экземпляр оборудования, которое должно физически отработать переданный ему запрос.

Гораздо свободнее может себя чувствовать разработчик драйвера псевдоустройства (программной модели): здесь каждый запрос open(будь то из одного последовательного потока, различных потоков процесса или даже из потоков, принадлежащих разным процессам) может порождать новый экземпляр псевдоустройства. Возвращаемый им файловый дескриптор (в QNX это дескриптор соединения) станет ссылаться на порожденный экземпляр, а вызовы read— write, оперирующие с различным дескриптором, будут направляться соответствующим различным экземплярам. (Понятно, что такой параллелизм операций может обеспечить только многопоточный менеджер ресурса, но нужно еще «заставить» его сделать это.)

Это настолько часто используемая модель, что она заслуживает отдельного рассмотрения. Дополнительную сложность создает то обстоятельство, что мы, как уже отмечалось, договорились писать программный код на С++, а здесь нам предстоит переопределять из своего кода определения в заголовочных файлах менеджера ресурсов, не нарушая их C-синтаксис.

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

Подмена стандартного Open Control Block

// предшествующие общие строки #include не показаны

// это переопределение нужно для исключения предупреждений

// компилятора: 'THREAD_POOL_PARAM_T' redefined

#define THREAD_POOL_PARAM_T dispatch_context_t #include

// следующее переопределение принципиально важно.

// оно предписывает вместо стандартного блока OCB (open control block),

// создаваемого вызовом клиента open и соответствующего его файловому

// дескриптору, использовать собственную структуру данных.

// Эта структура должнабыть производной от стандартной

// iofunc_ocb_t, а определение должно предшествовать

// включению

#define IOFUNC_OCB_T struct ownocb

#include

class ownocb public iofunc_ocb_t {

 static const int BUFSIZE = 1024;

public:

 char *buf;

 ownocb(void) { buf = new char[BUFSIZE]; }

 ~ownocb(void) { delete buf; }

};

IOFUNC_OCB_T *ownocb_calloc(resmgr_context_t *ctp, IOFUNC_ATTR_T *device) {

 return new ownocb;

}

void ownocb_free(IOFUNC_OCB_T *o) { delete o; }

iofunc_funcs_t ownocb_funcs = {

 _IOFUNC_NFUNCS, ownocb_calloc, ownocb_free

};

iofunc_mount_t mountpoint = { 0, 0, 0, 0, &ownocb_funcs };

// Вместо умалчиваемой операции iofunc_lock_ocb_default,

// вызываемой перед началом обработки запросов чтения/записи

// и блокирующей атрибутную запись, мы предписываем вызывать