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

#include

#include

#include

#include

#include

#include

#include

#include

#include

// обработчик запроса от клиента read(),

// возвращающий текущий приоритет обслуживания

static int prior_read(resmgr_context_t *ctp, io_read_t *msg,

RESMGR_OCB_T *ocb) {

static bool odd = true;

int status = iofunc_read_verify(ctp, msg, ocb, NULL);

if (status != EOK) return status;

if (msg->i.xtype & _IO_XTYPE_MASK != _ID_XTYPE_NONE)

return ENOSYS;

if (odd) {

struct sched_param param;

sched_getparam(0, &param);

static char rbuf[4];

sprintf(rbuf, "%d\n", param.sched_curpriority);

MsgReply(ctp->rcvid, strlen(rbuf) + 1, rbuf, strlen(rbuf) + 1);

} else MsgReply(ctp->rcvid, EOK, NULL, 0);

odd = !odd;

return _RESMGR_NOREPLY;

}

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

main(int argc, char **argv) {

resmgr_attr_t resmgr_attr;

dispatch_t *dpp;

dispatch_context_t *ctp;

int id;

// инициализация интерфейса диспетчеризации

if ((dpp = dispatch_create()) == NULL)

perror("allocate dispatch"), exit(EXIT_FAILURE);

// инициализация атрибутов менеджера

memset(&resmgr_attr, 0, sizeof resmgr_attr);

resmgr_attr.nparts_max = 1;

resmgr_attr.msg_max_size = 2048;

// инициализация таблиц функций обработчиков

static resmgr_connect_funcs_t connect_funcs;

static resmgr_io_funcs_t io_funcs;

iofunc_func_init(_RESMGR_CONNECT_NFUNCS, &connect_funcs,

_RESMGR_IO_NFUNCS, &io_funcs);

// здесь нами дописан всего один обработчик - операции read,

// все остальное делается менеджером по умолчанию!

io_funcs.read = prior_read;

// инициализация атрибутной структуры, используемой

// устройством.

static iofunc_attr_t attr;

iofunc_attr_init(&attr, S_IFNAM | 0666, 0, 0);

// здесь создается путевое имя для менеджера

id = resmgr_attach(dpp, &resmgr_attr, "/dev/prior",

_FTYPE_ANY, 0, &connect_funcs, &io_funcs, &attr);

if (id == -1)

perror("attach name"), exit(EXIT_FAILURE);

ctp = dispatch_context_alloc(dpp);

// старт менеджера как бесконечный цикл ожидания

// поступающих сообщений для диспетчеризации:

while (true) {

if ((ctp = dispatch_block(ctp)) == NULL)

perror("block error"), exit(EXIT_FAILURE);

dispatch_handler(ctp);

}

}

Здесь использован простейший однопоточный шаблон написания менеджера. Менеджер отрабатывает только одну команду read()(т.e. отрабатывает нестандартно; в целевом коде все остальные команды, например open(), он отрабатывает по умолчанию). По команде read()менеджер: а) возвращает в виде текстовой строки, завершающейся переводом строки, текущий приоритет (помните, что в QNX приоритеты «плавают»?), на котором он обрабатывает запрос, и б) делает это через один запрос, в оставшиеся разы создавая на всякий случай (почему «на всякий», сейчас станет понятно) ситуацию EOF (конца файла). Выполним несколько команд:

# prior &

# ls -l /dev/pr*

nrw-rw-rw- 1 root root 0 Dec 18 17:13 /dev/prior

Все соответствует нашим ожиданиям: менеджер ресурса запущен, он зарегистрировал в пространстве имен свое имя /dev/prior, по которому мы можем к нему обращаться. Теперь выполним обращения к нашему... «устройству». Для этого мы сознательно не станем пользоваться каким-либо специальным клиентом, запрашивающим наш созданный сервис, а воспользуемся самыми заурядными командами UNIX, которые ничего не подозревают о существовании нового сервиса:

# cat /dev/prior

10

# nice -n-5 cat /dev/prior

15

# nice -n-19 cat /dev/prior

29

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

Теперь разработка, например драйвера некоторого специфичного устройства, перемещается из области шаманства «системного программиста» в область деятельности проблемного программиста, да и выполняется привычными высокоуровневыми инструментальными средствами, например С++.

Пользуясь случаем, именно здесь уместно на примере созданного менеджера ресурсов продемонстрировать гибкость микроядерной архитектуры и техники менеджера ресурса, а заодно убедиться, что наследование приоритетов (критически важное свойство для систем реального времени) сохраняется при запросе к удаленному менеджеру ресурса, запущенному на другом узле сети (имя узла — rtp):