Помоги проекту - поделись книгой:
| Тип IPC | Живучесть определяет |
|---|---|
| Программный канал (pipe) | Процесс |
| Именованный канал (FIFO) | Процесс |
| Взаимное исключение Posix (mutex) | Процесс |
| Условная переменная Posix (condition variable) | Процесс |
| Блокировка чтения-записи Posix (lock) | Процесс |
| Блокировка записи fcntl | Процесс |
| Очередь сообщений Posix (message queue) | Ядро |
| Именованный семафор Posix (named semaphore) | Ядро |
| Семафор Posix в памяти (memory-based semaphore) | Процесс |
| Разделяемая память Posix (shared memory) | Ядро |
| Очередь сообщений System V | Ядро |
| Семафор System V | Ядро |
| Память с общим доступом System V | Ядро |
| Сокет TCP (TCP socket) | Процесс |
| Сокет UDP (UDP socket) | Процесс |
| Доменный сокет Unix (Unix domain socket) | Процесс |
Обратите внимание, что ни один тип IPC в этой таблице не обладает живучестью, определяемой файловой системой. Мы уже упомянули о том, что три типа объектов IPC в стандарте Posix
1.4. Пространства имен
Если два неродственных процесса используют какой-либо вид IPC для обмена информацией, объект IPC должен иметь имя или идентификатор, чтобы один из процессов (называемый обычно сервером — server) мог создать этот объект, а другой процесс (обычно один или несколько клиентов — client) мог обратиться к этому конкретному объекту.
Программные каналы (pipes) именами не обладают (и поэтому не могут использоваться для взаимодействия между неродственными процессами), но каналам FIFO сопоставляются имена в файловой системе, являющиеся их идентификаторами (поэтому каналы FIFO могут использоваться для взаимодействия неродственных процессов). Для других типов IPC, рассматриваемых в последующих главах, используются дополнительные соглашения об именовании (naming conventions). Множество возможных имен для определенного типа IPC называется его пространством имен (name space). Пространство имен — важный термин, поскольку для всех видов IPC, за исключением простых каналов, именем определяется способ связи клиента и сервера для обмена сообщениями.
В табл. 1.2 сведены соглашения об именовании для различных видов IPC.
Таблица 1.2. Пространства имен для различных типов IPC
| Тип IPC | Пространство имен для создания или открытия | Идентификатор после открытия | Posix.1 1996 | Unix 98 |
|---|---|---|---|---|
| Канал | (Без имени) | Дескриптор | • | • |
| FIFO | Имя файла (pathname) | Дескриптор | • | • |
| Взаимное исключение Posix | (Без имени) | Указатель типа pthread_mutex_t | • | • |
| Условная переменная Posix | (Без имени) | Указатель типа pthread_cond_t | • | • |
| Блокировка чтения-записи Posix | (Без имени) | Указатель типа pthread_rwlock_t | • | |
| Блокировка записей fcntl | Имя файла | Дескриптор | • | • |
| Разделяемая память Posix | Posix-имя IPC | Дескриптор | • | • |
| Очередь сообщений System V | Ключ key_t | Идентификатор IPC System V | • | |
| Семафор System V | Ключ key_t | Идентификатор IPC System V | • | |
| Разделяемая память System V | Ключ key_t | Идентификатор IPC System V | • | |
| Двери (doors) | Имя файла | Дескриптор | ||
| Удаленный вызов процедур (RPC) Sun | Программа/версия | Дескриптор (handle) RPC | ||
| Сокет TCP | IP-адрес и порт TCP | Дескриптор | .1g | • |
| Сокет UDP | IP-адрес и порт TCP | Дескриптор | .1g | • |
| Доменный сокет Unix (domain socket) | Полное имя файла | Дескриптор | .1g | • |
Здесь также указано, какие формы IPC содержатся в стандарте Posix.1 1996 года и какие были включены в стандарт Unix 98. Об обоих этих стандартах более подробно рассказано в разделе 1.7. Для сравнения мы включили в эту таблицу три типа сокетов, которые подробно описаны в [24]. Обратите внимание, что интерфейс сокетов (Application Program Interface — API) стандартизируется рабочей группой Posix.1g и должен в будущем стать частью стандарта Posix.1.
Хотя стандарт Posix. 1 и дает возможность использования семафоров, их поддержка не является обязательной для производителей. В табл. 1.3 сведены функции, описанные в стандартах Posix.1 и Unix 98. Каждая функция может быть обязательной (mandatory), неопределенной (not defined) или необязательной (дополнительной — optional). Для необязательных функций мы указываем имя константы (например, _POSIX_THREADS), которая будет определена (обычно в заголовочном файле <unistd.h>), если эта функция поддерживается. Обратите внимание, что Unix 98 содержит в себе Posix.1 в качестве подмножества.
Таблица 1.3. Доступность различных форм IPC
| Тип IPC | Posix.1 1996 | Unix 98 |
|---|---|---|
| Программный канал | Обязателен | Обязателен |
| FIFO | Обязателен | Обязателен |
| Взаимное исключение Posix | _POSIX_THREADS | Обязателен |
| Условная переменная Posix | _POSIX_THREADS | Обязателен |
| Взаимные исключения и условные переменные между процессами | _POSIX_THREADS_PROCESS_SHARED | Обязателен |
| Блокировка чтения-записи Posix | (He определен) | Обязателен |
| Блокировка записей fcntl | Обязателен | Обязателен |
| Очередь сообщений Posix | _POSIX_MESSAGE_PASSING | _XOPEN_REALTIME |
| Семафоры Posix | _POSIX_SEMAPHORES_ | _XOPEN_REALTIME |
| Память с общим доступом Posix | _POSIX_SHARED_MEMORY_OBJECTS | _XOPEN_REALTIME |
| Очередь сообщений System V | (He определен) | Обязателен |
| Семафор System V | (He определен) | Обязателен |
| Память с общим доступом System V | (He определен) | Обязателен |
| Двери (doors) | (He определен) | (Не определен) |
| Удаленный вызов процедур Sun | (He определен) | (Не определен) |
| Отображение памяти mmap | _POSIX_MAPPED_FILES или POSIX_SHARED_MEMORY_OBJECTS | Обязателен |
| Сигналы реального времени (realtime signals) | _POSIX_REALTIME_SIGNALS | _XOPEN_REALTIME |
1.5. Действие команд fork, exec и exit на объекты IPC
Нам нужно достичь понимания действия функций fork, exec и _exit на различные формы IPC, которые мы обсуждаем (последняя из перечисленных функций вызывается функцией exit). Информация по этому вопросу сведена в табл. 1.4.
Большинство функций описаны далее в тексте книги, но здесь нужно сделать несколько замечаний. Во-первых, вызов fork из многопоточного процесса (multithreaded process) приводит к беспорядку в безымянных переменных синхронизации (взаимных исключениях, условных переменных, блокировках и семафорах, хранящихся в памяти). Раздел 6.1 книги [3] содержит необходимые детали. Мы просто отметим в добавление к таблице, что если эти переменные хранятся в памяти с общим доступом и создаются с атрибутом общего доступа для процессов, они будут доступны любому процессу, который может обращаться к этой области памяти. Во-вторых, три формы IPC System V не могут быть открыты или закрыты. Из листинга 6.6 и упражнений 11.1 и 14.1 видно, что все, что нужно знать, чтобы получить доступ к этим трем формам IPC, — это идентификатор. Поэтому они доступны всем процессам, которым известен этот идентификатор, хотя для семафоров и памяти с общим доступом требуется некая особая обработка.
Таблица 1.4. Действие fork, exec и _exit на IPC
| Тип IPC | fork | exec | _exit |
|---|---|---|---|
| Неименованные и именованные каналы | Порожденный процесс получает копии всех дескрипторов родительского процесса | Все открытые дескрипторы остаются открытыми, если для них не установлен бит FD_CLOEXEC | Все открытые дескрипторы закрываются, данные из программного канала и FIFO удаляются после последнего закрытия |
| Очереди сообщений Posix | Порожденный процесс получает копии всех открытых родительских процессов | Все открытые дескрипторы очередей сообщений закрываются | Все открытые дескрипторы очередей сообщений закрываются |
| Очереди сообщений System V | Не действует | Не действует | Не действует |
| Взаимные исключения и условные переменные Posix | Общий доступ, если используется разделяемая память с атрибутом разделения между процессами | Исчезает, если не хранится в разделяемой памяти, которая остается открытой и имеет атрибут разделения | Исчезает, если не находится в разделяемой памяти, которая остается открытой и имеет атрибут разделения |
| Блокировки чтения-записи Posix | Общий доступ, если используется память с общим доступом и атрибутом разделения между процессами | Исчезает, если не хранится в разделяемой памяти, которая остается открытой и имеет атрибут разделения | Исчезает, если не хранится в разделяемой памяти, которая остается открытой и имеет атрибут разделения |
| Семафоры Posix, хранящиеся в памяти | Общий доступ, если используется память с общим доступом и атрибутом разделения между процессами | Исчезает, если не хранится в разделяемой памяти, которая остается открытой и имеет атрибут разделения | Исчезает, если не хранится в разделяемой памяти, которая остается открытой и имеет атрибут разделения |
| Именованные семафоры Posix | Все открытые в родительском процессе остаются открытыми в порожденном | Все открытые закрываются | Все открытые закрываются |
| Семафоры System V | Все значения semadj в порожденном процессе устанавливаются в 0 | Все значения semadj передаются новой программе | Все значения semadj добавляются к значению соответствующего семафора |
| Блокировка записей fcntl | Блокировки в родительском процессе не наследуются порожденным процессом | Блокировки не изменяются до тех пор, пока не закроется дескриптор | Все несброшенные блокировки, установленные процессом, снимаются |
| Отображение памяти | Отображения памяти родительского процесса сохраняются в порожденном | Отображения памяти сбрасываются (unmap) | Отображения памяти сбрасываются |
| Разделяемая память Posix | Отображения памяти родительского процесса сохраняются в порожденном | Отображения памяти сбрасываются | Отображения памяти сбрасываются |
| Разделяемая память System V | Присоединенные сегменты разделяемой памяти остаются присоединенными в порожденном процессе | Присоединенные сегменты разделяемой памяти отсоединяются | Присоединенные сегменты разделяемой памяти отсоединяются |
| Двери (doors) | Порожденный процесс получает копии всех открытых дескрипторов родительского процесса, но только родительский процесс является сервером при активизации дверей через дескрипторы | Все дескрипторы дверей должны быть закрыты, потому что они создаются с установленным битом FD_CLOEXEC | Все открытые дескрипторы закрываются |
1.6. Обработка ошибок: функции-обертки
В любой реальной программе при любом вызове требуется проверка возвращаемого значения на наличие ошибки. Поскольку обычно работа программ при возникновении ошибок завершается, мы можем сократить объем текста, определив функции-обертки (wrapper functions), которые осуществляют собственно вызов функции, проверяют возвращаемое значение и завершают работу при возникновении ошибок. В соответствии с соглашениями имена функций-оберток совпадают с именами самих функций, за исключением первой буквы, которая делается заглавной, например
Sem_post(ptr);
Пример функции-обертки приведен в листинге 1.1[1]
// lib/wrapunix.c
387 void
388 Sem_post(sem_t *sem)
389 {
390 if (sem_post(sem) == –1)
391 err_sys("sem_post error");
392 }
Если в тексте вы встретите имя функции, начинающееся с заглавной буквы, знайте: это наша собственная функция-обертка. Она вызывает функцию с тем же именем, начинающимся со строчной буквы. Функция-обертка приводит к завершению работы процесса с выводом сообщения об ошибке, если таковая возникает.
При описании исходного кода, включенного в книгу, мы всегда говорим о вызываемой функции самого низкого уровня (например, sem_post), а не о функции-обертке (например, Sem_post). Аналогично в алфавитном указателе приведены имена самих функций, а не оберток к ним.
ПРИМЕЧАНИЕ
Вышеприведенный формат исходного кода используется во всем тексте. Все непустые строки нумеруются. Текст, описывающий разделы кода, начинается с номеров первой и последней строк на пустом поле слева. Иногда перед абзацем текста присутствует краткий заголовок, набранный полужирным шрифтом, излагающий основное содержание описываемого кода.
В начале кода указывается имя исходного файла. В данном примере — это файл wrapunix.c в каталоге lib. Поскольку исходный код всех примеров этой книги распространяется свободно (см. предисловие), вы можете легко найти требуемый файл. Компиляция, выполнение и особенно изменение этих программ в процессе чтения книги — лучший способ изучить концепции взаимодействия процессов.
Хотя может показаться, что использовать такие функции-обертки не слишком выгодно, вы избавитесь от этого заблуждения в главе 7, где мы обнаружим, что функции для работы с потоками (thread functions) не присваивают значение стандартной переменной Unix errno при возникновении ошибки; вместо этого код ошибки просто возвращается функцией. Это означает, что при вызове функции pthread мы должны каждый раз выделять память под переменную, сохранять в ней возвращаемое функцией значение, а затем устанавливать значение переменной errno равным этой переменной, прежде чем вызывать функцию err_sys (листинг В.4). Чтобы не загромождать текст фигурными скобками, мы используем оператор языка Си «запятая» (comma) и совмещаем присваивание значения переменной errno и вызов err_sys в одном операторе, как в нижеследующем примере:
int n;
if ((n = pthread_mutex_lock(&ndone_mutex))!=0) errno=n, err_sys("pthread_mutex_lock error");
Альтернативой является определение новой функции обработки ошибок, принимающей код ошибки в качестве аргумента. Однако мы можем сделать этот фрагмент кода гораздо более читаемым, записав
Pthread_mutex_lock(&ndone_mutex);
где используется наша собственная функция-обертка, приведенная в листинге 1.2.
//lib/wrappthread.c
125 void
126 Pthread_mutex_lock(pthread_mutex_t *mptr)
127 {
128 int n;
129 if ((n=pthread_mutex_lock(mptr))==0)
130 return;
131 errno=n;
132 err_sys("pthread_mutex_lock error");
133 }
ПРИМЕЧАНИЕ
Аккуратно используя возможности языка Си, мы могли бы применять макросы вместо функций, что увеличило бы скорость выполнения программ, но эти функции-обертки редко бывают (если вообще бывают) узким местом.
Наше соглашение о замене первой буквы имени функции на заглавную является компромиссом. Рассматривалось много других форм записи: использование префикса е ([10, с. 182]), суффикса _е и т. д. Наш вариант кажется наименее отвлекающим внимание и одновременно дающим визуальное указание на то, что вызывается какая-то другая функция.
Этот метод имеет побочное полезное свойство: проверяются ошибки, возвращаемые функциями, код возврата которых обычно игнорируется, например close и pthread_ mutex_lock.
Далее в тексте книги мы будем использовать эти функции-обертки, если только не потребуется явно проверить наличие ошибки и обработать ее произвольным образом, отличным от завершения процесса. Мы не приводим в книге исходный код для всех оберток, но он свободно доступен в Интернете (см. предисловие).
Значение errno
При возникновении ошибки в функции Unix глобальной переменной errno присваивается положительное значение, указывающее на тип ошибки; при этом функция обычно возвращает значение –1. Наша функция err_sys выводит соответствующее коду ошибки сообщение (например, Resource temporarily unavailable — ресурс временно недоступен, — если переменная errno имеет значение EAGAIN).
Функция присваивает значение переменной errno только при возникновении ошибки. В случае нормального завершения работы значение этой переменной не определено. Все положительные значения соответствуют константам с именами из заглавных букв, начинающимися с Е, определяемым обычно в заголовочном файле <sys/errno.h>. Отсутствию ошибок соответствует значение 0.
При работе с несколькими потоками в каждом из них должна быть собственная переменная errno. Выделение переменной каждому потоку происходит автоматически, однако обычно это требует указания компилятору на то, что должна быть возможность повторного входа в программу. Задается это с помощью ключей –D_REENTRANT или –D_POSIX_C_SOURCE=199506L или аналогичных. Часто в заголовке <errno.h> переменная errno определяется как макрос, раскрываемый в вызов функции, если определена константа _REENTRANT. Функция обеспечивает доступ к копии errno, относящейся к данному потоку.
Далее в тексте мы используем выражения наподобие «функция mq_send возвращает EMSGSIZE», означающие, что функция возвращает ошибку (обычно возвращаемое значение при этом равно –1) и присваивает переменной errno значение указанной константы.
1.7. Стандарты Unix
В настоящее время стандарты Unix определяются Posix и The Open Group.
Posix
Название Posix образовано от «Portable Operating System Interface», что означает приблизительно «интерфейс переносимых операционных систем». Это не один стандарт, а целое семейство, разработанное Институтом инженеров по электротехнике и радиоэлектронике (Institute for Electrical and Electronics Engineers — IEEE). Стандарты Posix были также приняты в качестве международных стандартов ISO (International Organization for Standardization, Международная организация по стандартизации) и IEC (International Electrotechnical Commission, Международная электротехническая комиссия), или ISO/IEC. Стандарты Posix прошли несколько стадий разработки.
■ Стандарт IEEE 1003.1-1988 (317 страниц) был первым стандартом Posix. Он определял интерфейс взаимодействия языка С с ядром Unix-типа в следующих областях: примитивы для реализации процессов (вызовы fork, exec, сигналы и таймеры), среда процесса (идентификаторы пользователей, группы процессов), файлы и каталоги (все функции ввода-вывода), работа с терминалом, базы данных системы (файлы паролей и групп), форматы архивов tar и cpio.
ПРИМЕЧАНИЕ
Первый стандарт Posix вышел в рабочем варианте под названием IEEEIX в 1986 году. Название Posix было предложено Ричардом Штолманом (Richard Stallman).
■ Затем вышел стандарт IEЕЕ 1003.1-1990 (356 страниц). Он одновременно являлся и международным стандартом ISO/IEC 9945-1:1990. По сравнению с версией 1988 года изменения в версии 1990 года были минимальными. К заголовку было добавлено: «Part 1: System Application Program Interface (API) [C Language]» («Часть 1: Системный интерфейс разработки программ (API) [Язык С])», и это означало, что стандарт описывал программный интерфейс (API) языка С.
■ IEEE 1003.2-1992 вышел в двух томах общим объемом около 1300 страниц, и его заголовок содержал строку «Part 2: Shell and Utilities» (Часть 2: «Интерпретатор и утилиты»). Эта часть определяла интерпретатор (основанный на Bourne shell в Unix System V) и около ста утилит (программ, обычно вызываемых из интерпретатора — от awk и basename до vi и уасс). В настоящей книге мы будем ссылаться на этот стандарт под именем Posix. 2.
■ IEEE 1003.1b-1993 (590 страниц) изначально был известен как IEEE P1003.4. Этот стандарт представлял собой дополнение к стандарту 1003.1-1990 и включал расширения реального времени, разработанные рабочей группой Р1003.4: синхронизацию файлов, асинхронный ввод-вывод, семафоры, управление памятью, планирование выполнения (scheduling), часы, таймеры и очереди сообщений.
■ IEEE 1003.1, издание 1996 года [8] (743 страницы), включает 1003.1-1990 (базовый интерфейс API), 1003.1b-1993 (расширения реального времени), 1003.1-1995 (Pthreads — программные потоки Posix) и 1003.1i-1995 (технические поправки к 1003.1b). Этот стандарт также называется ISO/IEC 9945-1: 1996. В него были добавлены три главы о потоках и дополнительные разделы, касающиеся синхронизации потоков (взаимные исключения и условные переменные), планирование выполнения потоков, планирование синхронизации. В настоящей книге мы называем этот стандарт Posix.1.
ПРИМЕЧАНИЕ
Более четверти из 743 страниц стандарта представляли собой приложение, озаглавленное «Rationale and Notes» («Обоснование и примечания»). Это обоснование содержит историческую информацию и объяснение причин, по которым некоторые функции были или не были включены в стандарт. Часто обоснование оказывается не менее полезным, чем собственно стандарт.
К сожалению, стандарты IEEE не являются свободно доступными через Интернет. Информация о том, где можно заказать книгу, дана в библиографии под ссылкой [8]. Обратите внимание, что семафоры были определены в стандарте расширений реального времени, отдельно от взаимных исключений и условных переменных (которые были определены в стандарте Pthreads), что объясняет некоторые различия в интерфейсах API этих средств.
Наконец, заметим, что блокировки чтения-записи не являются частью стандартов Posix. Об этом более подробно рассказано в главе 8.
В будущем планируется выход новой версии IEEE 1003.1, включающей стандарт P1003.1g, сетевые интерфейсы (сокеты и XTI), которые описаны в первом томе этой книги.
В предисловии стандарта Posix.1 1996 года утверждается, что стандарт ISO/IEC 9945 состоит из следующих частей:
1. Системный интерфейс разработки программ (API) (язык С).
2. Интерпретатор и утилиты.
3. Администрирование системы (в разработке).
Части 1 и 2 представляют собой то, что мы называем Posix.1 и Posix.2.
Работа над стандартами Posix постоянно продолжается, и авторам книг, с ними связанных, приходится заниматься стрельбой по движущейся мишени. О текущем состоянии стандартов можно узнать на сайте http://www.pasc.org/standing/sd11.html.
The Open Group
The Open Group (Открытая группа) была сформирована в 1996 году объединением X/Open Company (основана в 1984 году) и Open Software Foundation (OSF, основан в 1988 году). Эта группа представляет собой международный консорциум производителей и потребителей из промышленности, правительства и образовательных учреждений. Их стандарты тоже выходили в нескольких версиях:
■ В 1989 году Х/Open опубликовала 3-й выпуск X/Open Portability Guide (Руководство по разработке переносимых программ) — XPG3.
■ В 1992 году был опубликован четвертый выпуск (Issue 4), а в 1994 году — вторая его версия (Issue 4, Version 2). Последняя известна также под названием Spec 1170, где магическое число 1170 представляет собой сумму количества интерфейсов системы (926), заголовков (70) и команд (174). Есть и еще два названия: X/Open Single Unix Specification (Единая спецификация Unix) и Unix 95.
■ В марте 1997 года было объявлено о выходе второй версии Единой спецификации Unix. Этот стандарт программного обеспечения называется также Unix 98, и именно так мы ссылаемся на эту спецификацию далее в тексте книги. Количество интерфейсов в Unix 98 возросло с 1170 до 1434, хотя для рабочей станции это количество достигает 3030, поскольку в это число включается CDE (Common Desktop Environment — общее окружение рабочего стола), которое, в свою очередь, требует системы X Window System и пользовательского интерфейса Motif. Подробно об этом написано в книге [9]. Полезную информацию можно также найти по адресу http://www.UNIX-systems.org/version2.
ПРИМЕЧАНИЕ
С этого сайта можно свободно скачать единую спецификацию Unix практически целиком.
Версии Unix и переносимость
Практически все версии Unix, с которыми можно столкнуться сегодня, соответствуют какому-либо варианту стандарта Posix.1 или Posix.2. Мы говорим «какому-либо», потому что после внесения изменений в Posix (например, Добавление расширений реального времени в 1993 и потоков в 1996) производителям обычно требуется год или два, чтобы подогнать свои программы под эти стандарты.
Исторически большинство систем Unix являются потомками либо BSD, либо System V, но различия между ними постепенно стираются, по мере того как производители переходят к использованию стандартов Posix. Основные различия лежат в области системного администрирования, поскольку ни один стандарт Posix на данный момент не описывает эту область.
В большинстве примеров этой книги мы использовали операционные системы Solaris 2.6 и Digital Unix 4.0B. Дело в том, что на момент написания книги (конец 1997 — начало 1998 года) только эти две операционные системы поддерживали System V IPC, Posix IPC и программные потоки Posix (Pthreads).
1.8. Комментарий к примерам IPC
Чаще всего для иллюстрации различных функций в книге используются три шаблона (модели) взаимодействия:
1. Сервер файлов: приложение клиент-сервер, причем клиент посылает серверу запрос с именем файла, а сервер возвращает клиенту его содержимое.
2. Производитель-потребитель: один или несколько потоков или процессов (производителей) помещают данные в буфер общего пользования, а другие потоки или процессы (потребители) производят с этими данными различные операции.
3. Увеличение последовательного номера: один или несколько потоков или процессов увеличивают общий для всех индекс. Число это может храниться в файле с общим доступом или в совместно используемой области памяти.
Первый пример иллюстрирует различные формы передачи сообщений, а других два — разнообразные виды синхронизации и использования разделяемой памяти.
Таблицы 1.5, 1.6 и 1.7 представляют собой своего рода путеводитель по разрабатываемым нами программам на различные темы, изложенные в книге. В этих таблицах кратко описаны сами программы и указаны номера соответствующих листингов.
1.9. Резюме
Взаимодействие процессов традиционно является одной из проблемных областей в Unix. По мере развития системы предлагались различные решения, и ни одно из них не было совершенным. Мы подразделяем IPC на четыре главных типа.
1. Передача сообщений (каналы, FIFO, очереди сообщений).
2. Синхронизация (взаимные исключения, условные переменные, блокировки чтения-записи, семафоры).
3. Разделяемая память (неименованная и именованная).
4. Вызов процедур (двери в Solaris, RPC Sun).
Поделиться книгой: