2. Переносимость (вспомните табл. 1.3). Практически все системы под управлением Unix поддерживают именованные и неименованные каналы и блокировку записей стандарта Posix. К 1998 году большинство систем поддерживало средства IPC System V (очереди сообщений, семафоры и разделяемую память), тогда как лишь немногие поддерживали те же средства стандарта Posix. Должны появиться новые реализации Posix IPC, но, к сожалению, эти средства не являются обязательными в стандарте Unix 98. Многие системы поддерживают потоки Posix (включая взаимные исключения и условные переменные) или станут поддерживать их в ближайшем будущем. Некоторые системы, поддерживающие потоки Posix, не воспринимают атрибут использования между процессами для взаимных исключений и условных переменных. Блокировки чтения-записи, требуемые стандартом Unix 98, должны вскоре войти в стандарт Posix, и множество систем уже поддерживают какой-либо из видов таких блокировок. Отображение в память распространено достаточно широко, и большинство Unix-систем поддерживают неименованное отображение (с использованием либо /dev/zero, либо MAP_ANON). Средства Sun RPC должны быть доступны практически на всех системах Unix, тогда как двери пока реализованы только в Solaris.
3. Производительность. Если для вашего приложения критична скорость работы средств IPC, воспользуйтесь программами из приложения А. Лучше всего изменить эти программы для имитации среды, в которой будет работать ваше приложение, и таким образом измерить скорость работы средств IPC в этой среде.
4. Планирование в реальном времени. Если вам нужно воспользоваться этой функцией и система ее поддерживает, рассмотрите возможность использования функций Posix для передачи сообщений и синхронизации (очереди сообщений, семафоры, взаимные исключения и условные переменные). Например, когда увеличиваются значения семафора, в вызове к которому заблокировано несколько потоков, разблокируемый поток выбирается в соответствии с политиками планирования и параметрами заблокированных потоков. Для семафоров System V это не гарантируется.
Чтобы помочь вам понять некоторые особенности и ограничения средств IPC, мы вкратце перечислим основные различия между ними:
■ Именованные и неименованные каналы представляют собой потоки байтов без грaниц между сообщениями. Очереди сообщений Posix и System V предусматривают наличие границ сообщений. Сравните это с протоколами Интернета: TCP — это поток байтов, a UDP — последовательность сообщений с явно определенными границами.
■ Очереди сообщений Posix могут отправлять процессу сигнал или запускать новый поток в случае, если в пустую очередь помещается сообщение. Для очередей System V такая возможность не предусматривается. Ни один из типов очередей сообщений не может быть использован непосредственно с вызовами select и poll (глава 6 [24]), хотя некие решения этой проблемы были приведены при обсуждении листинга 5.12 и в разделе 6.9.
■ Данные в именованных и неименованных каналах передаются в порядке очереди (FIFO). Очереди сообщений Posix и System V предусматривают возможность присваивания сообщениям различного приоритета. При чтении из очереди Posix всегда возвращается сообщение с наивысшим приоритетом. Для очередей System V можно указать любой конкретный тип сообщения.
■ При помещении сообщения в очередь Posix или System V или в именованный или неименованный канал ровно один экземпляр доставляется ровно одному считывающему потоку. Возможность передачи нескольким адресатам отсутствует (в отличие от сокетов и XTI при использовании протокола UDP — главы 18 и 19 [24]).
■ Взаимные исключения, условные переменные и блокировки чтения-записи имен не имеют. Они могут легко использоваться потоками одного процесса. Совместное использование их различными процессами возможно только в случае, если эти объекты располагаются в общей для этих процессов области памяти. Семафоры Posix бывают двух типов: именованные и размещаемые в памяти. Именованные семафоры могут использоваться только различными процессами (они идентифицируются именами Posix IPC), а размещаемые в памяти должны для этого находиться в разделяемой памяти. Семафоры System V также являются именованными (с помощью типа key_t), они также могут без проблем использоваться несколькими процессами совместно.
■ Блокировки записей fcntl автоматически снимаются ядром при завершении процесса, если он сам об этом не позаботится. Для семафоров System V эта возможность является дополнительной. Для взаимных исключений, условных переменных, блокировок чтения-записи и семафоров Posix эта возможность не предусматривается.
■ Каждая блокировка fcntl действует на некоторый диапазон байтов (называемый записью) в файле, указываемом с помощью дескриптора. Блокировки чтения-записи не связываются ни с какими записями.
■ Разделяемая память Posix и System V обладает живучестью ядра. Она существует до тех пор, пока не будет удалена явно, даже если в какой-то момент не используется ни одним процессом.
■ Размер объекта разделяемой памяти Posix может быть увеличен в процессе работы. Размер сегмента разделяемой памяти System V фиксируется при его создании.
■ Oгрaничeния ядра на три типа System V IPC часто требуют настройки вручную, поскольку устанавливаемые для них по умолчанию значения часто не соответствуют требованиям реальных приложений (раздел 3.8). Oгрaничeния на средства Posix IPC обычно не требуют настройки.
■ Информация об объектах System V IPC (текущий размер, идентификатор владельца, время последнего изменения и т. п.) возвращается вызовом одной из функций XXXctl с командой IPC_STAT и пpoгрaммoй ipcs. Для получения информации об объектах Posix стандартных способов не предусматривается. Если реализация использует файлы в качестве основы для этих объектов, можно получить эту информацию с помощью функции stat или программы ls, если нам известен способ преобразования имени Posix IPC в полное имя файла. Если же в данной реализации файлы не используются, способа получить такую информацию может и не существовать.
■ Из всех средств синхронизации — взаимных исключений, условных переменных, блокировок чтения-записи, блокировок записи, семафоров — только две функции можно вызывать из обработчика сигналов (табл. 5.1): sem_post и fcntl.
■ Из всех средств передачи сообщений — каналов, очередей сообщений Posix и System V — только две функции могут быть вызваны из обработчика сигналов: read и write (используются с именованными и неименованными каналами).
■ Из всех средств передачи сообщений только двери предоставляют серверу точную информацию о клиенте (раздел 15.5). В разделе 5.4 мы упомянули два других способа передачи сообщений, которые также предоставляют информацию о клиенте: доменные сокеты в BSD/OS (раздел 14.8 [24]) и каналы в SVR4, если по ним передается дескриптор файла (раздел 15.3.1 [21]).
ПРИЛОЖЕНИЕ АИзмерение производительности
А.1. Введение
В основной части книги мы перечислили шесть средств передачи сообщений:
■ неименованные каналы (pipes);
■ именованные каналы (FIFO);
■ очереди сообщений Posix;
■ очереди сообщений System V;
■ двери;
■ SunRPC.
Кроме того, мы указали пять типов средств синхронизации:
■ взаимные исключения и условные переменные;
■ блокировки чтения-записи;
■ блокировка записей fcntl;
■ семафоры Posix;
■ семафоры System V.
В этом приложении мы разработаем набор простых программ для измерения производительности этих видов IPC, чтобы иметь возможность аргументировать свой выбор одного из этих средств для конкретной задачи.
При сравнении средств передачи сообщений нас интересуют два параметра:
1. Полоса пропускания (bandwidth) — скорость передачи данных по каналу IPC. Для измерения этого параметра мы передаем огромное количество данных (миллионы байтов) от одного процесса другому. Этот параметр измеряется для различных объемов данных на операцию (например, write и read для каналов), и мы ожидаем, что полоса пропускания будет увеличиваться вместе с увеличением количества передаваемых за одну операцию данных.
2. Задержка (latency) определяется как время, которое требуется небольшому сообщению, чтобы проделать путь по каналу IPC от одного процесса к другому и обратно. Мы измеряем время задержки для сообщения размером 1 байт.
В реальности величина полосы пропускания говорит нам о том, сколько времени будет потрачено на передачу блока данных по каналу IPC, но IPC также используется и для передачи небольших управляющих сообщений. Задержка определяет время, необходимое для передачи этих сообщений. Важными оказываются обе величины.
Чтобы измерить скорость работы средств синхронизации, мы изменим программу, увеличивающую значение счетчика в разделяемой памяти. Поскольку увеличение — элементарная операция, время будет тратиться в основном на работу средств синхронизации.
ПРИМЕЧАНИЕ
Программы этого приложения, используемые для измерения производительности средств IPC, основаны на пакете lmbench [15]. Этот пакет содержит набор тестов, измеряющих множество параметров системы (скорость переключения контекста и т. п.), а не только производительность средств IPC. Исходный код пакета доступен по адресу http://www.bitmover.com/lmbench.
Величины, приведенные в этом приложении, дают нам возможность сравнить методы, описанные в книге. Заодно мы хотели показать, как просто измерить эти величины. Прежде чем останавливать свой выбор на одном из средств IPC, нелишне было бы получить эти значения в вашей собственной системе. К сожалению, насколько легко измерить величины, настолько же трудно объяснить аномальное их поведение в отсутствие доступа к исходному коду ядра и библиотек.
А.2. Результаты
Сведем вместе результаты, полученные в этом приложении. Данный раздел может использоваться как справочник при чтении книги.
Для проведения измерений использовались две системы: SparcStation 4/110 под управлением Solaris 2.6 и Digital Alpha (DEC 3000 model 300, Pelican) под управлением Digital Unix 4.0В. В файл /etc/system системы Solaris 2.6 были добавлены следующие строки:
set msgsys:msginfo_msgmax = 16384set msgsys:msginfo_msgmnb = 32768set msgsys:msginfo_msgseg = 4096Это дает возможность отправлять сообщения размером 16384 байт в очередь сообщений System V (табл. А.2). Те же изменения осуществляются в Digital Unix 4.0B введением следующих строк с помощью программы sysconfig:
ipc: msg-max = 16384 msg-mnb = 32768Результаты измерения полосы пропускания сообщений
В табл. А.2 приведены результаты измерений на компьютере Sparc под управлением Solaris 2.6, а на рис. А.1 — график этих результатов.
Как мы и предполагали, полоса пропускания увеличивается с размером сообщения. Поскольку во многих реализациях очередей сообщений System V ограничение на размер сообщения, установленное в ядре, достаточно мало (раздел 3.8), максимальный размер сообщения в нашей программе имеет значение 16384 байт.
Уменьшение полосы для сообщений размером около 4096 байт в Solaris 2.6, возможно, связано с настройкой внутренних ограничений ядра. Для сравнения с [24] мы приводим результаты аналогичных измерений для сокета TCP и доменного сокета Unix. Эти две величины были получены с помощью программ пакета lmbench для сообщений размером 65536 байт. При измерении быстродействия сокета TCP оба процесса выполнялись на одном узле.
Результаты измерения задержки
В табл. А.1 приведены значения задержки в Solaris 2.6 и Digital Unix 4.0B.
Таблица А.1. Задержка при передаче сообщения размером 1 байт (в микросекундах)
| Канал | Очередь сообщений Posix | Очередь сообщений System V | Двери | Sun RPC TCP | Sun RPC UDP | Сокет TCP | Сокет UDP | Доменный сокет | |
|---|---|---|---|---|---|---|---|---|---|
| Solaris 2.6 | 324 | 584 | 260 | 121 | 1891 | 1677 | 798 | 755 | 465 |
| DUnix 4.0B | 574 | 995 | 625 | 1648 | 1373 | 848 | 639 | 289 |
Рис. А.1. Полоса пропускания средств передачи сообщений в Solaris 2.6.
В разделе A.4 мы приведем листинги программ, использованных для получения первых четырех величин, а оставшиеся три получены с помощью пакета lmbench. При измерении скорости работы TCP и UDP оба процесса находились на одном узле.
Таблица А.2. Полоса пропускания для разных типов сообщений в Solaris 2.6 (Мбайт/с)
| Размер сообщения | Канал | Очередь сообщений Posix | Очередь сообщений System V | Двери | Sun RPC TCP | Sun RPC UDP | Сокет TCP | Доменный сокет |
|---|---|---|---|---|---|---|---|---|
| 1024 | 6,3 | 3,7 | 4,9 | 6,3 | 0,5 | 0,5 | ||
| 2048 | 8,7 | 5,3 | 6,3 | 10,0 | 0,9 | 1,0 | ||
| 4096 | 9,8 | 8,4 | 6,6 | 12,6 | 1,6 | 2,8 | ||
| 8192 | 12,7 | 10,2 | 5,8 | 14,4 | 2,4 | 2,8 | ||
| 16384 | 13,1 | 11,6 | 6,1 | 16,8 | 3,2 | 3,4 | ||
| 32768 | 13,2 | 13,4 | 11,4 | 3,5 | 4,3 | |||
| 65536 | 13,7 | 14,4 | 12,2 | 3,7 | 13,2 | 11,3 |
Рис. А.2. Полоса пропускания для различных средств передачи сообщений (Digital Unix 4.0B)
Таблица А.З. Полоса пропускания для различных типов сообщения в Digital Unix 4.0B (Мбайт/с)
| Размер сообщения | Канал | Очередь сообщений Posix | Очередь сообщений System V | Sun RPC TCP | Sun RPC UDP | Сокет TCP | Доменный сокет |
|---|---|---|---|---|---|---|---|
| 1024 | 9,9 | 1,8 | 12,7 | 0,6 | 0,6 | ||
| 2048 | 15,2 | 3,5 | 15,0 | 0,8 | 1,0 | ||
| 4096 | 17,1 | 5,9 | 21,1 | 1,3 | 1,8 | ||
| 8192 | 16,5 | 8,6 | 17,1 | 1,8 | 2,5 | ||
| 16384 | 17,3 | 11,7 | 17,3 | 2,3 | |||
| 32768 | 15,9 | 14,0 | 2,6 | ||||
| 65536 | 14,2 | 9,4 | 2,8 | 4,6 | 18,0 |
Результаты синхронизации потоков
В табл. А.4 приведены значения времени, нужного одному или нескольким потокам для увеличения счетчика в разделяемой памяти с использованием различных средств синхронизации в Solaris 2.6, а на рис. А.3 показан график этих значений. Каждый поток увеличивает значение счетчика 1000000 раз, а количество потоков меняется от 1 до 5. В табл. А.5 приведены эти же значения для Digital Unix 4.0В, а на рис. А.4 — график этих значений.
Рис. А.З. Время увеличения счетчика в разделяемой памяти (Solaris 2.6)
Мы увеличиваем количество потоков, чтобы проверить правильность кода. Кроме того, при добавлении потоков время работы программы может начать расти нелинейно. Блокировка fcntl может использоваться только одним потоком, поскольку эта форма синхронизации предназначена только для использования между несколькими процессами, а не потоками одного процесса.
В Digital Unix 4.0B значения для семафоров Posix оказываются непомерно большими, если работает более одного потока, что указывает на наличие какой-то аномалии. На графике мы эти значения не приводим.
ПРИМЕЧАНИЕ
Одна из возможных причин этой аномалии заключается в том, что в этой программе синхронизация проверяется неправильно. В данном случае потоки не делают ничего полезного, и все время уходит на синхронизацию. Поскольку потоки создаются с внутрипроцессной конкуренцией, при потере управления потоком блокировка сохраняется, поэтому поток, получающий управление, выполняться дальше не может.
Рис.А.4. Время увеличения счетчика в разделяемой памяти (Digital Unix 4.0B)
Таблица А.4. Время увеличения счетчика в разделяемой памяти для Solaris 2.6 (в секундах)
| Кол-во потоков | Взаимное исключение Posix | Блокировка чтения-записи | Семафор Posix в памяти | Именованный семафор Posix | Семафор System V | Семафор System V с UNDO | Блокировка записей fcntl |
|---|---|---|---|---|---|---|---|
| 1 | 0,7 | 2,0 | 4,5 | 15,4 | 16,3 | 21,1 | 89,4 |
| 2 | 1,5 | 5,4 | 9,0 | 31,1 | 31,5 | 37,5 | |
| 3 | 2,2 | 7,5 | 14,4 | 46,5 | 48,3 | 57,7 | |
| 4 | 2,9 | 13,7 | 18,2 | 62,5 | 65,8 | 75,8 | |
| 5 | 3,7 | 19,7 | 22,8 | 76,8 | 81,8 | 90,0 |
Таблица А.5. Время увеличения счетчика в разделяемой памяти в Digital Unix 4.0B (в секундах)
| Кол-во потоков | Взаимное исключение Posix | Блокировка чтения-записи | Семафор Posix в памяти | Именованный семафор Posix | Семафор System V | Семафор System V с UNDO | Блокировка записей fcntl |
|---|---|---|---|---|---|---|---|
| 1 | 2,9 | 12,9 | 13,2 | 14,2 | 26,6 | 46,6 | 96,4 |
| 2 | 11,4 | 40,8 | 742,5 | 771,6 | 54,9 | 93,9 | |
| 3 | 28,4 | 73,2 | 1080,5 | 1074,5 | 84,5 | 141,9 | |
| 4 | 49,3 | 95,0 | 1534,1 | 1502,2 | 109,9 | 188,4 | |
| 5 | 67,3 | 126,3 | 1923,3 | 1764,1 | 137,3 | 233,6 |
Результаты синхронизации процессов
В табл. А.4 и А.5 и на соответствующих рисунках были приведены результаты синхронизации потоков одного процесса. Интересно посмотреть, как взаимодействуют разные процессы. В табл. А.6 и на рис. А.5 приведены результаты измерения времени увеличения счетчика несколькими процессами в Solaris 2.6, а в табл. А.7 и на рис. А.6 — в Digital Unix 4.0B. Результаты похожи на полученные для потоков, однако в Solaris 2.6 теперь получаются одинаковые результаты для первых двух типов семафоров. Мы приводим на графике только первое значение для fcntl, поскольку последующие слишком велики. Как отмечалось в разделе 7.2, Digital Unix 4.0B не поддерживает атрибут PTHREAD_PROCESS_SHARED, поэтому мы не можем измерить скорость работы взаимных исключений в этой системе. Для семафоров Posix в Digital Unix 4.0B опять наблюдаются аномалии.
Рис. А.5. Время увеличения счетчика в разделяемой памяти (Solaris 2.6)
Рис. А.6. Время увеличения счетчика в разделяемой памяти
Таблица А.6. Время увеличения счетчика в разделяемой памяти для Solaris 2.6 (в секундах)
| Кол-во процессов | Взаимное исключение Posix | Блокировка чтения-записи | Семафор Posix в памяти | Именованный семафор Posix | Семафор System V | Семафор System V с UNDO | Блокировка записей fcntl |
|---|---|---|---|---|---|---|---|
| 1 | 0,8 | 1,6 | 13,6 | 14,3 | 17,3 | 22,1 | 90,7 |
| 2 | 1,6 | 3,9 | 29,2 | 29,2 | 34,9 | 41,6 | 244,5 |
| 3 | 2,3 | 6,4 | 41,6 | 42,9 | 54,0 | 60,1 | 376,4 |
| 4 | 3,1 | 12,2 | 57,3 | 58,8 | 72,4 | 81,9 | 558,0 |
| 5 | 4,0 | 20,4 | 70,4 | 73,5 | 87,8 | 102,6 | 764,0 |
Таблица А.7. Время увеличения счетчика в разделяемой памяти для Digital Unix 4.0B (в секундах)
| Количество процессов | Семафор Posix в памяти | Именованный семафор Posix | Семафор System V | Семафор System V с UNDO | Блокировка записей fcntl |
|---|---|---|---|---|---|
| 1 | 12,8 | 12,5 | 30,1 | 49,0 | 98,1 |
| 2 | 664,8 | 659,2 | 58,6 | 95,7 | 477,1 |
| 3 | 1236,1 | 1269,8 | 96,4 | 146,2 | 1785,2 |
| 4 | 1772,9 | 1804,1 | 120,3 | 197,0 | 2582,8 |
| 5 | 2179,9 | 2196,8 | 147,7 | 250,9 | 3419,2 |
А.З. Измерение полосы пропускания: программы