QNX/UNIX: Анатомия параллелизма
QNX/UNIX: Анатомия параллелизма читать книгу онлайн
Книга адресована программистам, работающим в самых разнообразных ОС UNIX. Авторы предлагают шире взглянуть на возможности параллельной организации вычислительного процесса в традиционном программировании. Особый акцент делается на потоках (threads), а именно на тех возможностях и сложностях, которые были привнесены в технику параллельных вычислений этой относительно новой парадигмой программирования. На примерах реальных кодов показываются приемы и преимущества параллельной организации вычислительного процесса. Некоторые из результатов испытаний тестовых примеров будут большим сюрпризом даже для самых бывалых программистов. Тем не менее излагаемые техники вполне доступны и начинающим программистам: для изучения материала требуется базовое знание языка программирования C/C++ и некоторое понимание «устройства» современных многозадачных ОС UNIX.
В качестве «испытательной площадки» для тестовых фрагментов выбрана ОСРВ QNX, что позволило с единой точки зрения взглянуть как на специфические механизмы микроядерной архитектуры QNX, так и на универсальные механизмы POSIX. В этом качестве книга может быть интересна и тем, кто не использует (и не планирует никогда использовать) ОС QNX: программистам в Linux, FreeBSD, NetBSD, Solaris и других традиционных ОС UNIX.
Внимание! Книга может содержать контент только для совершеннолетних. Для несовершеннолетних чтение данного контента СТРОГО ЗАПРЕЩЕНО! Если в книге присутствует наличие пропаганды ЛГБТ и другого, запрещенного контента - просьба написать на почту [email protected] для удаления материала
MsgError(rcvid, ENOSYS);
continue;
}Получив от клиента некое предопределенное сообщение, сервер сбрасывает флаг
flagWorkС учетом этих деталей и организован нижеописанный сервер.
Код процесса-сервера, использующего службу глобальных имен
#include <stdio.h>
#include <errno.h>
#include <stdlib.h>
#include <sys/dispatch h>
/* На сервер могут приходить и импульсы. Как минимум. */
typedef struct _pulse msg_header_t;
/* Структура сообщения состоит из заголовка и буфера наших данных */
typedef struct _MsgBuf {
msg_header_t hdr;
char* Buffer;
} MsgBuf_t;
int main() {
name_attach_t* NameServer;
MsgBuf_t MsgBuf;
int rcvid;
char BufReply[100];
int flagWork = 1;
/* Создаем глобальное имя /dev/name/global/MyService */
if (!(NameServer = name_attach(NULL, "MyService",
NAME_FLAG_ATTACH_GLOBAL)))
return EXIT_FAILURE;
/* Становимся на петлю получения сообщений */
while (flgWork) {
if ((rcvid = MsgReceive(NameServer->chid, &MsgBuf,
sizeof MsgBuf, NULL)) == -1) {
printf("Ошибка при получении сервером MyService "
"сообщения от клиентаn");
fflush(stdout);
break;
}
if (!rcvid) {
// Получен импульс
switch(MsgBuf.hdr.code) {
case _PULSE_CODE_DISCONNECT:
/* Поскольку для канала установлен флаг _NTO_CHF_DISCONNECT, ядро
автоматически не освобождает связи, установленные клиентом ранее.
Сервер должен выполнить это со своей стороны сам, "сознательно"
удалив маршрут от себя обратно к клиенту */
ConnectDetach(MsgBuf.hdr.scoid);
break;
case _PULSE_CODE_UNBLOCK;
/* Клиент пытается разблокироваться, не дождавшись ответа по Reply. Надо
выполнить какие-то действия, чтобы корректно (для себя)
обработать эту ситуацию, и все-таки отпустить этого клиента - ему
ведь надо! При этом импульсе в MsgBuf.hdr.value приходит rcvid */
MsgReply(MsgBuf.hdr.value.sival_int, EAGAIN, NULL, 0);
break;
default:
break;
}
continue;
// вновь уходим на петлю приема сообщений
}
/* Полученное сообщение находится в диапазоне системных сообщений
ввода/вывода. Не обрабатываем. */
if (MsgBuf.hdr.type >= _IO_BASE && MsgBuf.hdr.type <= _IO_MAX) {
MsgError(rcvid, ENOSYS);
continue;
}
/* А вот это - сообщение для сервера. Обрабатываем. */
if (MsgBuf.hdr.type <= 0x50001 || MsgBuf.hdr.type >= 0x500ff) {
printf("Сервер получил сообщение неизвестно от"
" кого с меткой %#xn", MsgBuf.hdr.type);
strcpy(BufReply, "а кто это???");
} else {
printf("Сервер получил сообщение. "%s"n",
MsgBuf.Buffer);
strcpy(BufReply, "а, это ты, клиент");
}
MsgReply(rcvid, EOK, BufReply, strlen(BufReply) + 1);
}
// Конец петли получения сообщений
/* Отсоединяемся от службы глобальных имен */
name_detach(NameServer, 0);
return EXIT_SUCCESS;
}Приложения-клиенты, которым надо использовать глобальную службу имен, могут использовать функцию API
name_open()• Если поставщик службы имеется на том же узле, что и приложение, запросившее службу, менеджер пытается связать приложение прежде всего с локальным поставщиком. Если связь успешна, приложение общается со своим поставщиком локально, что обеспечивает лучшую производительность.
• Если локальный поставщик отсутствует или по каким-то причинам отказывает в поставке службы, менеджер пытается связать приложение с другими поставщиками. Если имеется несколько удаленных поставщиков, то порядок, в котором производятся попытки установить с ними связь (т.е. кто получит связь первым), не определен.
