Помоги проекту - поделись книгой:
Уильям Стивенс
UNIX: взаимодействие процессов
МАСТЕР-КЛАСС
Всему сообществу Usenet, где можно найти много ЧаВо с ответами на все вопросы и случаи жизни
Предисловие
Большинство нетривиальных программ пишутся с использованием одной из форм межпроцессного взаимодействия (IPC — Interprocess Communication). Это естественное следствие принципа разработки, заключающегося в том, что лучше создавать приложение, состоящее из отдельных взаимодействующих элементов, чем одну большую программу. Исторически разработка приложений пережила следующие этапы развития:
1. Сначала были большие цельные программы, которые делали все необходимое. Отдельные части программы реализовывались в виде функций, обменивавшихся информацией через аргументы, возвращаемые значения и глобальные переменные.
2. Потом стали создаваться небольшие программы, взаимодействующие друг с другом посредством различных средств IPC. Многие стандартные утилиты Unix были разработаны именно таким образом, причем для передачи информации использовались каналы интерпретатора.
3. Наконец, сейчас появилась возможность писать цельные программы, состоящие из взаимодействующих между собой потоков. В данном случае мы все равно применяем термин IPC, хотя процесс имеется только один.
Комбинация последних двух вариантов также возможна: несколько процессов, каждый из которых состоит из нескольких потоков, вполне могут взаимодействовать между собой.
Мы описываем возможность разделения решаемых задач между несколькими процессами или даже между потоками одного процесса. В мультипроцессорной системе такое приложение сможет выполняться гораздо быстрее, поэтому разделение задач между процессами способно повысить его быстродействие.
В этой книге подробно описываются четыре формы IPC:
1. Передача сообщений (каналы, FIFO, очереди сообщений).
2. Синхронизация (взаимные исключения, условные переменные, блокировки чтения-записи, блокировка файлов и записей, семафоры).
3. Разделяемая память (неименованная и именованная).
4. Удаленный вызов процедур (двери, Sun RPC).
Здесь не рассматриваются вопросы написания программ, взаимодействующих по сети. Такая форма взаимодействия обычно подразумевает использование интерфейса сокетов и стека протоколов TCP/IP; эти темы были подробно разобраны в первом томе книги ([24]).
Нам могут возразить, что средства IPC, не предназначенные для взаимодействия по сети, вообще не следует использовать и что вместо этого следует изначально разрабатывать приложения с расчетом на использование в сети. Однако на практике средства IPC, работающие только в пределах одного узла, функционируют гораздо быстрее, чем сетевые, да и программы с их использованием оказываются проще. Разделяемая память и средства синхронизации обычно не могут использоваться по сети — они доступны только в пределах одного узла. Опыт и история показывают, что существует потребность в наличии как несетевых, так и сетевых форм IPC.
В этой книге используется материал первого тома и других моих книг:
■ UNIX Network Programming, том 1, 1998 [24];
■ Advanced Programming in the UNIX Environment, 1992 [21];
■ TCP/IP Illustrated, том 1, 1994 [22];
■ TCP/IP Illustrated, том 2, написанной в соавторстве с Гари Райтом (Gary Wright),1995, [27];
■ TCP/IP Illustrated, том 3, 1996 [23].
Может показаться странным, что я описываю средства IPC в книге, заглавие которой содержит слова «Network Programming». Замечу, что IPC часто используется и в сетевых приложениях. Как говорилось в предисловии к книге «UNIX Network Programming» 1990 года издания, «для понимания методов разработки сетевых приложений необходимо понимание средств межпроцессного взаимодействия (IPC)».
Этот том содержит полностью переписанные главы 3 и 18 книги «UNIX Network Programming» 1990 года издания. Если подсчитать количество слов, объем материала увеличился в пять раз. Ниже перечислены основные отличия данного издания:
■ В дополнение к трем формам System V IPC (очереди сообщений, семафоры, разделяемая память) рассматриваются более новые функции Posix, реализующие эти же три формы IPC. О стандартах Posix более подробно говорится в разделе 1.7. В будущем можно ожидать перехода к использованию функций Posix, обладающих определенными преимуществами по сравнению с аналогами System V.
■ Рассматриваются средства синхронизации Posix: взаимные исключения, условные переменные, блокировки чтения-записи. Эти средства могут использоваться для синхронизации потоков или процессов и часто привлекаются для обеспечения синхронизации доступа к разделяемой памяти.
■ В этом томе предполагается наличие поддержки потоков Posix (Pthreads), и многие примеры написаны с использованием многопоточного (а не многопроцессного) программирования.
■ Описание именованных и неименованных каналов и блокировок записей основано на их определениях в стандарте Posix.
■ В дополнение к описанию средств IPC и примерам их использования я также привожу примеры реализации очередей сообщений, блокировок чтения-записи и семафоров Posix (все это может быть скомпилировано в пользовательские библиотеки). Эти реализации задействуют множество разных средств одновременно. Например, одна из реализаций семафоров Posix использует взаимные исключения, условные переменные и отображение в память. В комментариях отмечаются важные моменты, которые следует учитывать при разработке приложений (ситуации гонок, обработка ошибок, утечка памяти, использование списков аргументов переменной длины). Понимание реализации какого-либо средства ведет к лучшему его использованию.
■ При описании RPC основное внимание уделяется пакету Sun RPC. Рассказ предваряется описанием нового интерфейса дверей в Solaris, который похож на RPC, но используется только в пределах одного узла. Описание дверей является как бы введением, в котором описываются важные вопросы вызова процедур в других процессах без необходимости учитывать особенности сетевой реализации.
Эта книга может использоваться как учебник по IPC или как справочник для опытных программистов. Текст разделен на четыре части:
■ передача сообщений;
■ синхронизация;
■ разделяемая память;
■ удаленный вызов процедур.
Возможно, некоторые читатели будут интересоваться содержимым конкретных подразделов. Большая часть глав может читаться совершенно независимо от остальных, хотя в главе 2 объединены многие общие особенности средств Posix IPC, в главе 3 — System V IPC, а глава 12 является введением в разделяемую память (как Posix, так и System V). Всем читателям настоятельно рекомендуется прочесть главу 1, в особенности раздел 1.6, в котором описываются используемые в книге функции-обертки. Главы, описывающие средства Posix IPC, могут читаться отдельно от глав, посвященных System V IPC. Описание каналов и блокировок записей стоит особняком. Две главы, посвященные удаленному вызову процедур, также могут читаться отдельно от прочих.
Подробный индекс упрощает использование книги в качестве справочника. Для читающих текст в случайном порядке приводятся многочисленные перекрестные ссылки на сходный материал.
Исходный код всех примеров можно загрузить с домашней страницы автора (адрес — в конце предисловия). Лучший способ изучить IPC — это изменить программы из примеров или даже улучшить их. Написание программ лучше всего способствует усвоению концепций и методов. В конце каждой главы даются упражнения, решения к большей части которых даны в приложении Г.
Список замеченных опечаток можно также найти на домашней странице автора.
Хотя на обложке книги стоит имя только одного автора, в ее создании участвовало множество людей. Прежде всего это члены семьи автора, которые смирились с ушедшими на ее написание часами. Еще раз спасибо, Салли, Билл, Эллен и Дэвид.
Спасибо всем, кто помогал работать с содержимым книги. Ваша помощь была просто неоценимой (135 печатных страниц). Вы исправляли ошибки, отмечали недостаточную четкость пояснений, предлагали другие объяснения и варианты программ. Спасибо вам, Гевин Боуи, Аллен Бриггс, Дейв Бутенхов, Ван-Тех Чанг, Крис Клилэнд, Боб Фриснан, Эндрю Гиерт, Скотт Джонсон, Марти Леиснер, Ларри Мак-Вой, Крейг Метз, Боб Нельсон, Стив Рэго, Джим Рейд, Свами К. Ситарама, Джон К. Снейдер, Иан Ланс Тейлор, Рик Тир и Энди Такер.
Мне помогали и те, кто отвечал на мои электронные письма, в которых порой было множество вопросов. Ваши ответы помогли сделать книгу более точной и ясной: Дэвид Баусум, Дейв Бутенхов, Билл Голмейстер, Макеш Кэкер, Брайан Керниган, Ларри МакВой, Стив Рэго, Кейт Скорвран, Барт Смаалдерс, Энди Такер и Джон Уэйт.
Отдельная благодарность Ларри Рафски из GSquared. Спасибо, как обычно, говорю я NOAO, Сиднею Вульфу, Ричарду Вульфу и Стиву Гранди за возможность работать с их сетями и компьютерами. Джим Баунд, Мэтт Томас, Мэри Клаутер и Барб Гловер из Digital Equipment Corp. предоставили систему Alpha, на которой выполнялась большая часть примеров данной книги. Часть программ была протестирована и в других системах. Спасибо Майклу Джонсону из Red Hat Software (за новейшие версии Red Hat Linux), Дейву Маркуардту и Джесси Хауг за компьютер RS/6000 и доступ к последним версиям AIX.
Благодарю сотрудников Prentice Hall — редактора Мэри Франц вместе с Норин Регина, Софи Папаниколау и Патти Гуэрриери — за помощь, в особенности в соблюдении сроков.
Оригинал-макет этой книги был подготовлен на языке PostScript. Форматирование осуществлялось с помощью замечательного пакета groff (автор — Джеймс Кларк) на SparcStation под управлением Solaris 2.6. (Сведения о смерти groff сильно преувеличены). Я набил все 138 897 слов книги в редакторе vi, создал 72 рисунка с помощью программы gpic (используя макросы Гари Райта), сделал 35 таблиц с помощью программы gtbl, подготовил индекс (с помощью сценариев на языке awk, написанных Джоном Бентли и Брайаном Керниганом) и сверстал все это вместе. Программа Дейва Хэнсона loom, пакет GNU indent и сценарии Гари Райта помогли добавить в книгу 8046 строк исходного кода на языке С.
С нетерпением жду комментариев, предложений и сообщений о замеченных опечатках.
W. Richard Stevens Tucson, Arizona July 1998
rstevens@kohala.com http://www.kohala.com/~rstevens
Ваши замечания, предложения, вопросы отправляйте по адресу электронной почты comp@piter.com (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
Все исходные тексты, приведенные в книге, вы можете найти по адресу http://www.piter.com/download.
На web-сайте издательства http://www.piter.com вы найдете подробную информацию о наших книгах.
ЧАСТЬ 1
ВВЕДЕНИЕ В IPC UNIX
ГЛАВА 1
Обзор средств взаимодействия процессов Unix
1.1. Введение
Аббревиатура IPC расшифровывается как
В процессе развития операционных систем семейства Unix за последние 30 лет методы передачи сообщений эволюционировали следующим образом:
■ Каналы (pipes — глава 4) были первой широко используемой формой взаимодействия процессов, доступной программам и пользователю (из интерпретатора команд). Основным недостатком каналов является невозможность их использования между процессами, не имеющими общего родителя (ancestor), но этот недостаток был устранен с появлением именованных каналов (named pipes), или каналов FIFO (глава 4).
■ Очереди сообщений стандарта System V (System V message queues — глава 4) были добавлены к ядрам System V в начале 80-х. Они могут использоваться для передачи сообщений между процессами на одном узле вне зависимости от того, являются ли эти процессы родственными. Несмотря на сохранившийся префикс «System V», большинство современных версий Unix, включая и те, которые не произошли от System V, поддерживают эти очереди.
ПРИМЕЧАНИЕ
В отношении процессов Unix термин «родство» означает, что у процессов имеется общий предок. Подразумевается, что процессы, являющиеся родственниками, были созданы этим процессом-предком с помощью одной или нескольких «вилок» (forks). Простейшим примером будет вызов fork некоторым процессом дважды, что приведет к созданию двух порожденных процессов. Тогда можно говорить о родстве этих процессов между собой. Естественно, каждый порожденный процесс является родственником породившего. Родитель может позаботиться о возможности взаимодействия с порожденным процессом (создав канал или очередь сообщений) перед вызовом fork, и этот объект IPC будет унаследован порожденным процессом. Более подробно о наследовании объектов IPC рассказано в табл. 1.4. Нужно также отметить, что все процессы Unix теоретически являются потомками процесса init, который запускает все необходимое в процессе загрузки системы (bootstrapping). С практической точки зрения отсчет родства процессов лучше вести с оболочки (login shell) и всех процессов, ею созданных. В главе 9 [24] рассказано о сеансах и родственных отношениях процессов более подробно.
ПРИМЕЧАНИЕ
Примечания вроде этого будут использоваться нами для того, чтобы уточнять особенности реализации, давать исторические справки и полезные советы.
■ Очереди сообщений Posix (Posix message queues — глава 5) были добавлены в стандарт Posix (1003.1b-1993, о котором более подробно рассказано в разделе 1.7). Они могут использоваться для взаимодействия родственных и неродственных процессов на каком-либо узле.
■ Удаленный вызов процедур (remote procedure calls — RPC, часть 5) появился в 80-х в качестве средства для вызова функций на одной системе (сервере) программой, выполняемой на другой системе (клиенте). Это средство было разработано в качестве альтернативы для упрощения сетевого программирования. Поскольку между клиентом и сервером обычно передается информация (передаются аргументы для вызова функции и возвращаемые значения) и поскольку удаленный вызов процедур может использоваться между клиентом и сервером на одном узле, RPC можно также считать одной из форм передачи сообщений.
Интересно также взглянуть на эволюцию различных форм синхронизации в процессе развития Unix:
■ Самые первые программы, которым требовалась синхронизация (чаще всего для предотвращения одновременного изменения содержимого файла несколькими процессами), использовали особенности файловой системы, некоторые из которых описаны в разделе 9.8,
■ Возможность блокирования записей (record locking — глава 9) была добавлена к ядрам Unix в начале 80-х и стандартизована в версии Posix.1 в 1988.
■ Семафоры System V (System V semaphores — глава 11) были добавлены вместе с возможностью совместного использования памяти (System V shared memory — глава 14) и одновременно с очередями сообщений System V (начало 80-х). Эти IPC поддерживаются большинством современных версий Unix.
■ Семафоры Posix (Posix semaphores — глава 10) и разделяемая память Posix (Posix shared memory— глава 13) были также добавлены в стандарт Posix (1003.1b-1993, который ранее упоминался в связи с очередями сообщений Posix).
■ Взаимные исключения и условные переменные (mutex, conditional variable — глава 7) представляют собой две формы синхронизации, определенные стандартом программных потоков Posix (Posix threads, Pthreads — 1003.1с-1995). Хотя обычно они используются для синхронизации между потоками, их можно применять и при организации взаимодействия процессов.
■ Блокировки чтения-записи (read-write locks — глава 8) представляют собой дополнительную форму синхронизации. Она еще не включена в стандарт Posix, но, вероятно, скоро будет.
1.2. Процессы, потоки и общий доступ к информации
В традиционной модели программирования Unix в системе могут одновременно выполняться несколько процессов, каждому из которых выделяется собственное адресное пространство. Это иллюстрирует рис. 1.1.
Рис. 1.1. Совместное использование информации процессами
1. Два процесса в левой части совместно используют информацию, хранящуюся в одном из объектов файловой системы. Для доступа к этим данным каждый процесс должен обратиться к ядру (используя функции read, write, lseek, write, lseek и аналогичные). Некоторая форма синхронизации требуется при изменении файла, для исключения помех при одновременной записи в файл несколькими процессами и для защиты процессов, читающих из файла, от тех, которые пишут в него.
2. Два процесса в середине рисунка совместно используют информацию, хранящуюся в ядре. Примерами в данном случае являются канал, очередь сообщений или семафор System V. Для доступа к совместно используемой информации в этом случае будут использоваться системные вызовы.
3. Два процесса в правой части используют общую область памяти, к которой может обращаться каждый из процессов. После того как будет получен доступ к этой области памяти, процессы смогут обращаться к данным вообще без помощи ядра. В этом случае, как и в первом, процессам, использующим общую память, также требуется синхронизация.
Обратите внимание, что ни в одном из этих случаев количество взаимодействующих процессов не ограничивается двумя. Любой из описанных методов работает для произвольного числа взаимодействующих процессов. На рисунке мы изображаем только два для простоты.
Потоки
Хотя концепция процессов в системах Unix используется уже очень давно, возможность использовать несколько потоков внутри одного процесса появилась относительно недавно. Стандарт потоков Posix.1, называемый Pthreads, был принят в 1995 году. С точки зрения взаимодействия процессов все потоки одного процесса имеют общие глобальные переменные (то есть поточной модели свойственно использование общей памяти). Однако потокам требуется синхронизация доступа к глобальным данным. Вообще, синхронизация, не являясь собственно формой IPC, часто используется совместно с различными формами IPC для управления доступом к данным.
В этой книге описано взаимодействие между процессами и между потоками. Мы предполагаем наличие среды, в которой поддерживается многопоточное программирование, и будем использовать выражения вида «если канал пуст, вызывающий поток блокируется до тех пор, пока какой-нибудь другой поток не произведет запись в канал». Если система не поддерживает потоки, можно в этом предложении заменить «потоки» на «процессы» и получится классическое определение блокировки в Unix, возникающей при считывании из пустого канала командой read. Однако в системе, поддерживающей потоки, блокируется только поток, запросивший данные из пустого канала, а все остальные потоки процесса будут продолжать выполняться. Записать данные в канал сможет другой поток этого же процесса или какой-либо поток другого процесса.
В приложении Б сведены некоторые основные характеристики потоков и дано описание пяти основных функций Pthread, используемых в программах этой книги.
1.3. Живучесть объектов IPC
Можно определить живучесть (persistence) любого объекта IPC как продолжительность его существования. На рис. 1.2 изображены три возможные группы, к которым могут быть отнесены объекты по живучести.
Рис. 1.2. Живучесть объектов IPC
1. Объект IPC, живучесть которого определяется процессом (process-persistent), существует до тех пор, пока не будет закрыт последним процессом, в котором он еще открыт. Примером являются неименованные и именованные каналы (pipes, FIFO).
2. Объект IPC, живучесть которого определяется ядром (kernel-persistent), существует до перезагрузки ядра или до явного удаления объекта. Примером являются очереди сообщений стандарта System V, семафоры и разделяемая память. Живучесть очередей сообщений Posix, семафоров и разделяемой памяти должна определяться по крайней мере ядром, но может определяться и файловой системой в зависимости от реализации.
3. Объект IPC, живучесть которого определяется файловой системой (filesystem-persistent), существует до тех пор, пока не будет удален явно. Его значение сохраняется даже при перезагрузке ядра. Очереди сообщений Posix, семафоры и память с общим доступом обладают этим свойством, если они реализованы через отображаемые файлы (так бывает не всегда).
Следует быть аккуратным при определении живучести объекта IPC, поскольку она не всегда очевидна. Например, данные в канале (pipe) обрабатываются ядром, но живучесть каналов определяется процессами, а не ядром, потому что после того, как последний процесс, которым канал был открыт на чтение, закроет его, ядро сбросит все данные и удалит канал. Аналогично, хотя каналы FIFO и обладают именами в файловой системе, живучесть их также определяется процессами, поскольку все данные в таком канале сбрасываются после того, как последний процесс, в котором он был открыт, закроет его.
В табл. 1.1 сведена информация о живучести перечисленных ранее объектов IPC.
Таблица 1.1. Живучесть различных типов объектов IPC
Поделиться книгой: