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

При обмене с менеджером ресурсов, в силу необходимости приведения клиентских запросов в «прокрустово ложе» POSIX, картина принципиально другая: каждый запрос может оперировать только с данными той длины, которая предопределена стандартом.

1. Команды группы readмогут передать в направлении сервера только код команды, уточненный параметрами (например, длина запрашиваемых данных), но не данные. В ответ сервер может передать клиенту данные произвольнойдлины. Обмен данными однонаправленный, в направлении от сервера к клиенту.

2. Команды группы writeмогут передать от клиента к серверу данные произвольнойдлины, но в ответ сервер может возвратить только код результата - число байт, фактически успешно полученных в результате операции. Обмен данными однонаправленный, в направлении от клиенту к серверу.

3. Команда devctl, использующаяся обычно для организации канала управления (но это не обязательно), в зависимости от кода команды может передавать данные либо к серверу (подобно write), либо от сервера (подобно read), либо в обоих направлениях за один обмен. Таким образом, этой командой может быть организован двунаправленныйобмен. Вообще говоря, принято считать, что по devctlпередаются данные фиксированнойдлины: длина передаваемого блока данных определяется непосредственно кодом команды. Но это не является серьезным ограничением: мы можем динамически формировать код команды перед обменом исходя из объема данных, подлежащих передаче (как это будет показано в примере следующего раздела). Такой трюк позволяет организовать обмен данными произвольнойдлины. Ограничение здесь состоит в другом: объемы данных, передаваемые по devctlв обоих направлениях, должны быть равны! А это, согласитесь, не совсем то, что мы видели при простом обмене сообщениями.

4. Наконец, последним вариантом обмена с менеджером ресурса является обмен «сырыми», неформатированными сообщениями. Но это уже вариация простого обмена сообщениями, а как ее реализовать в коде, показано в приложении В. Зайцева.

С другой стороны, такая повышенная гибкость простого обмена сообщениями в отношении размеров передаваемых данных — предмет потенциальных ошибок, в то время как регламентируемое POSIX поведение обменных функций несет в себе дополнительный контроль корректности.

Эффективность реализации

Если техника менеджеров ресурсов — это только надстройка над базовым механизмом обмена сообщениями, то возникает совершенно естественный вопрос: какова же плата за использование этого производительного и «комфортного» механизма?

Для анализа «скоростных» характеристик альтернативных механизмов обмена сообщениями создадим группу приложений (клиентские и сервер, файлы cli.cc, clr.ccи srv.cc), а чтобы отдельно не выписывать определения, используемые приложениями, вынесем их в отдельный файл определений ( файл common.h).

Общие определения проекта

const char VERSION[] = "vers. 1.03";

// имя, под которым будет регистрироваться в пространстве

// имен наш тестовый менеджер ресурса

static const char DEVNAME[_POSIX_PATH_MAX] = "/dev/srr";

// "базовая часть" команды devctl, конкретный код команды будет

// формироваться динамически на основе этой части, но исходя

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

const unsigned int DCMD_CMD = 1,

 DCMD_SRR = _POSIX_DEVDIR_TOFROM + (_DCMD_NET << 8) + DCMD_CMD;

// структура ответов менеджера ресурса по запросу read

struct result {

 pid_t pid;

 int chid;

 uint64_t cps;

 result(void) {

  pid = getpid;

  // если уж возвращать, то и служебную информацию ;)

  cps = SYSPAGE_ENTRY(qtime)->cycles_per_sec;

 }

}

// завершение с извещением кода причины

inline void exit(const char *msg) {

 cout << '\r';

 perror(msg);

 exit(EXIT_FAILURE);

}