Роб Кёртен - Введение в QNX/Neutrino 2. Руководство по программированию приложений реального времени в QNX Realtime Platform

Другая группа изменений, которые вы заметите при переносе приложений из QNX4 в QNX/Neutrino, особенно на другие платформы, касается того, что процессоры MIPS и PPC уж больно вычурны по части выравнивания. Вы не можете обращаться к N-байтовому объекту иначе чем по адресу, кратному N. При работе на x86 (с выключенным флагом выравнивания) вы бы волей-неволей обратились к памяти. Изменив вашу программу так, чтобы все структуры были правильно выровнены (для не-x86 процессоров), вы также заметите, что ваша программа после этого на x86 станет выполняться быстрее, потому что x86 быстрее обращается к выровненным данным.

Другое, что так часто не дает людям жить — это порядок следования байт, прямой (big-endian) или обратный (little-endian). (Кому интересна этимология этих терминов, загляните в английский оригинал «Путешествий Гулливера» Джонатана Свифта :-) — прим. ред .). У процессора x86 возможен только один порядок следования байт, и он обратный. Процессоры MIPS и PPC допускают оба порядка следования байт, т. е. могут работать как с прямым, так и с обратным. Кроме того, процессоры MIPS и PPC являются процессорами типа RISC (с сокращенным набором команд), что означает, что некоторые операции типа |= в Си (установка бита) могут и не быть атомарными. Это иногда приводит к жутким последствиям! Список вспомогательных функций, которые обеспечивают атомарность выполняемой операции, приведен в файле .

Существующие версии QNX4 работают только на однопроцессорных системах, в то время как QNX/Neutrino уже на момент публикации первого издания этой книги обеспечивала поддержку SMP по меньшей мере на архитектуре x86. SMP дает значительные преимущества, особенно в многопоточной ОС, но это одновременно и гораздо более серьезный пистолет для простреливания ноги (кто любопытен, поищите в Интернет по ключевой фразе «shoot yourself in the foot» — прим. ред .).

Например, в однопроцессорной машине обработчик прерывания (ISR) может вытеснить поток, но наоборот никогда не бывает . В однопроцессорной машине бывает полезно представить себе, что потоки якобы выполняются одновременно, хотя в действительности это не так.

В блоке SMP поток и обработчик прерывания могут работать одновременно, да и несколько потоков тоже могут работать одновременно. Так что SMP — это не только превосходная рабочая станция, но и неплохое средство тестирования программного обеспечения — если вы сделали какие бы то ни было «плохие» предположения о защите в многопоточной среде, в SMP-системе они однажды обязательно выплывут.

Для иллюстрации того, насколько это верно, один пример. Одна из ошибок в ранней внутренней версии поддержки SMP проявлялась в «окне» длиной в один машинный цикл! То, что для однопроцессорной машины было запрограммировано как атомарная операция «чтение/модификация/запись», в SMP-блоке стало допускать вмешательство в ход операции второго процессора, выполняющего «сравнение/обмен».

Давайте теперь взглянем на все «сверху». Здесь мы рассмотрим:

• обмен сообщениями и систему «клиент/сервер»;

• обработчики прерываний (ISR).

В QNX4 клиент мог найти сервер двумя способами:

• используя глобальное пространство имен;

• выполнение open() в отношении администратора ввода/вывода.

Если взаимоотношения «клиент/сервер, которые вы переносите, базируются на глобальном пространстве имен, тогда клиент использует:

qnx_name_locate()

а сервер регистрирует свое имя при помощи:

qnx_name_attach()

В этом случае у вас есть два выбора. Вы можете либо попробовать сохранить вариант с глобальными именами, либо модифицировать клиента и сервер так, чтобы они работали подобно стандартному администратору ресурсов.

Я рекомендую вам последний вариант, поскольку именно этот вариант характерен для QNX/Neutrino — сводить все к администраторам ресурсов, а не пытаться навесить кусок администратора ресурсов на службу глобальных имен.

Модификация будет достаточно проста. Скорее всего, клиентская сторона вызывает функцию, либо возвращающую идентификатор серверного процесса, либо создающую виртуальный канал («VC» — Virtual Circuit) от клиентского узла к удаленному узлу сервера. В обоих случаях как идентификатор процесса, так и идентификатор виртуального канала к удаленному процессу определяются при помощи qnx_name_locate() . «Магическим амулетом», связывающим клиента с сервером, здесь является специальная разновидность идентификатора процесса (мы считаем идентификатор виртуального канала идентификатором процесса, поскольку он берется из того же пула номеров и со всех точек зрения выглядит как идентификатор процесса).

Преодолеть основное различие можно было бы, возвращая вместо идентификатора процесса идентификатор соединения. Поскольку клиент в QNX4, вероятно, не анализирует идентификаторы процессов (да и зачем? Так, просто число), вы могли бы «обмануть» его, применив к «глобальному имени» функцию open() . В этом случае, однако, глобальное имя должно было бы быть точкой монтирования, зарегистрированной администратором ресурса в качестве своего «идентификатора». Вот, например, типовой пример клиента QNX4, взятый из моей серверной библиотеки CLID:

/*

* CLID_Attach(ServerName)

*

* Эта подпрограмма отвечает за установление соединения

* с сервером CLID.

*

* Возвращает PID сервера CLID или идентификатор

* виртуального канала к нему.

*/

// Сюда запишется имя - для других библиотечных вызовов

static char CLID_serverName(MAX_CLID_SERVER_NAME + 1);

// Сюда запишется идентификатор сервера

CLID static int clid_pid = -1;

int CLID_Attach(char *serverName) {

if (ServerName == NULL) {

sprintf(CLID_serverName, "/PARSE/CLID");

} else {

strcpy(CLID_serverName, serverName);

}

clid_pid = qnx_name_locate(0, CLID_serverName,

sizeof(CLID_ServerIPC), NULL);

if (clid_pid != -1) {

CLID_IPC(CLID_MsgAttach); // Послать сообщение ATTACH

return (clid_pid);

}

return (-1);

}

Вы могли бы изменить это на следующее:

/*

* CLID_Attach(serverName), версия для QNX/Neutrino

*/

int CLID_Attach(char *serverName) {

if (ServerName == NULL) {

sprintf(CLID_serverName, "/PARSE/CLID");

} else {

strcpy(CLID_serverName, serverName);

}

return (clid_pid = open(CLID_serverName, O_RDWR));

}

И клиент ничего бы не заметил.

Два замечания по реализации. В качестве зарегистрированного префикса администратора ресурса я просто оставил имя по умолчанию (« /PARSE/CLID »). Вероятно, лучше было бы взять имя « /dev/clid », но насколько вы хотите следовать POSIX — это ваше личное дело. В любом случае, это незначительное изменение, и оно мало связано с тем, что здесь обсуждается.