Олег Цилюрик - QNX/UNIX - Анатомия параллелизма

}

int main(int argc, char *argv[]) {

// проверка, не загружен ли ранее экземпляр менеджера,

// 2 экземпляра нам ни к чему...

char sDirName[_POSIX_NAME_MAX + 1];

int nDirLen = strrchr((const char*)sResName, '/') - (char*)sResName;

strncpy(sDirName, sResName, nDirLen);

sDirName[nDirLen] = '\0';

DIR *dirp = opendir(sDirName);

if (dirp == NULL)

perror("directory not found"), exit(EXIT_FAILURE);

struct dirent *direntp;

while (true) {

if ((direntp = readdir(dirp)) == NULL) break;

if (strcmp(direntp->d_name, strrchr(sResName, '/') + 1) == 0)

cout << "second copy of manager" << endl, exit(EXIT_FAILURE);

}

closedir(dirp);

// старт менеджера

StartResMng();

// ... к этой точке мы уже никогда не подойдем...

exit(EXIT_SUCCESS);

}

В отличие от типового и привычного шаблона многопоточного менеджера, мы проделали здесь дополнительно следующее:

• Определили собственную структуру OCB, новый экземпляр которой должен создаваться для каждого нового подключающегося клиента:

class ownocb : public iofunc_ocb_t { ... };

• Переопределили описание структуры OCB, используемое библиотеками менеджера ресурсов:

#define IOFUNC_OCB_T struct ownocb

• Заполняя атрибутную запись устройства:

attr.mount = &mountpoint;

мы к точке монтирования «привязываем» функции создания и уничтожения вновь определенной структуры OCB (по умолчанию библиотека менеджера станет размещать только стандартный OCB):

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().