/* ожидать десятикратного срабатывания таймеров ,*,/: for ( int i =0 ; i < 10; i++) ,

/* выполнять другую работу до срабатывания таймеров */ pause О;

/* показать время, оставшееся до срабатывания таймеров */ cerr . tl: tl endl;

cerr t2: t2 endl; cerr t3: t3 endl;

/* показать статистику потерь сигналов таймеров */ cerr tl overrun: tl.overrunO endl; cerr t2 overrun: t2.overrun() endl; cerr , t3 overrun: t3.overrun() endl;

return 0;

В этой программе создаются три таймера. Первый таймер срабатывает каждые 2 секунды и генерирует сигнал SIGINT; второй таймер срабатывает каждые 3,5 секунды и генерирует сигнал SIGUSRl; третий таймер срабатывает каждые 5 секунд и генерирует сигнал SIGUSR2. Обработчик для всех этих сигналов - функция callme (при желании пользователи могут использовать и другую функцию).

После создания объектов класса timer программа входит в цикл и ждет, пока поступят десять прерываний от любого из таймеров. Для каждого прерывания она выводит на экран (с помощью функции callme) идентификатор сработавшего таймера, а также текущие значения времени и даты. Кроме того, с помощью функции main программа выводит на экран время, оставшееся до срабатывания каждого таймера. После десяти прерываний программа выводит на экран статистику потерь сигналов и завершает свою работу. Объекты класса timer >Ничтожаются неявно с помощью функции timer::~timer, когда выполнение программы завершается.

Пробный запуск этой программы дал следующие результаты:

% СС timer.с % a.ot

timer id: 1, signo: 2, Sun Apr 20 13:00:29 1ЭЭ7

tl: time left: 1.99944

t2: time left: 1.49698

t3: time left: 2.99601 timer id: 2, signo: 16, Sun Apr 20 13:00:31 1997

tl: time left: 0.504464

t2: time left: 3.50374

t3: time left: 1.50304 timer id: 1, signo: 2, Sun Apr 20 13:00:31 1997

tl: time left: 2.0047

t2: time left: 3.00398

t3:, time timer id: 3, tl: time t2: time t3: time timer id: 1, tl: time t2: time t3: time timer id: 2, tl: time t2: time t3: time timer id: 1, tl: time t2: time t3: time timer id: 3, timer id: 1, tl: time t2: time t3: time timer id: 2, tl: time t2: time t3: time timer id: 1, tl: time t2: time t3: time tl overrun: t2 overrun: t3 overrun:

left:

signo

left:

left:

left:

signo

left:

left:

left:

signo

left

left

left

signo

left:

left:

left:

signo

signo

left:

left:

left:

signo

left:

left:

left:

signo

left:

left:

left:

1.00327 Hf

: 17, Sun Apr 20 13:00:32 1997

1.00468

2.00397

5.00326

: 2, Sun Apr 20 13:00:33 1997 2.0047 1.00398 4.00251

: 16, Sun Apr 20 13:00:34 1997 1.00467 3.50385 3.00313

: 2, Sun Apr 20 13:00:35 1997

2.0047

2.50399

2.00328

: 17, Sun Apr 20 13:00:37 1997 : 2, Sun Apr 20 13:00:37 1997

2.00309

0.502374

5.00143

: 6, Sun Apr 20 13:00:38 1997 1.50468 3.50396 4.50325

: 2, Sun Apr 20 13:00:39 1997 2.00468 2.00385 3.00313

9.12. Заключение

В этой главе описываются методы обработки сигналов, принятые в системах UNIX и POSIX. 1, а также различные ситуации из числа тех, когда процесс может посылать сигналы в другие процессы и самому себе. Основное назначение сигналов - управление процессами. В частности, с помощью сигналов пользователи, ядро и процессы могут прерывать зависшие процессы.

Кроме того, сигналы можно использовать для реализации некоторых простых средств межпроцессного взаимодействия. Например, два процесса могут инсталлировать обработчик сигнала SIGUSRl и синхронизировать свое выполнение, посылая друг другу этот сигнал. В следующей главе рассматриваются более сложные методы межпроцессного взаимодействия, используемые в системах UNIX и POSIX. 1.

Сигналы используются и для реализации интервальных таймеров. С помощью интервальных таймеров можно контролировать выполнение процессами определенных задач (когда эти процессы требуют синхронизации), устанавливать время выполнения операций. В данной главе представлены методы реализации интервальных таймеров, применяемые в системах UNIX и POSIX.l. Описывается класс timer, облегчающий применение таймеров в пользовательских приложениях. К преимуществам класса timer можно отнести то, что он создает упрощенный интерфейс, хорошо приспособленный для определения таймеров и манипулирования ими, содействует многократному использованию кода и уменьшает затраты на перенос приложений в другие системы. Кроме того, этот класс можно свободно встраивать в другие пользовательские классы, расширяя таким образом их функциональные возможности.

ГЛАВА

Межпроцессное взаимодействие

Межпроцессное взаимодействие (1п1ефгосе55 communication, IPC) - это механизм, с помощью которого два и более процессов осуществляют друг с другом взаимодействие, направленное на выполнение определенных задач. Эти процессы могут работать по схеме клиент/сервер (когда один или несколько процессов-клиентов посылают данные в центральный процесс-сервер, а последний отвечает каждому клиенту) или по одноранговой схеме (когда любой процесс может обмениваться данными с другими процессами). В качестве примера приложений, пользующихся межпроцессным взаимодействием, можно привести серверы баз данных и соответствующие клиентские программы (вариант клиент/сервер), а также системы электронной почты (одноранговая схема), в которых процесс-почтальон взаимодействует с другими процессами-почтальонами с целью передачи и приема сообщений.

Межпроцессное взаимодействие поддерживают все UNIX-системы, но в каждой из них этот механизм реализован по-своему. В частности, в BSD UNIX взаимодействие процессов, работающих на разных машинах, осуществляется с помощью так называемых гнезд (sockets). В UNIX System V.3 и V.4 взаимодействие процессов, работающих на одной машине, обеспечивается посредством сообщений, семафоров и разделяемой (shared) памяти, а межмашинное взаимодействие осуществляется с помощью интерфейса транспортного уровня (TLI). Кроме того, в UNIX System V.4 поддерживаются гнезда, благодаря чему возможен перенос в нее приложений, которые их используют. Наконец, и в BSD, и в UNIX System V для реализации внутри-машинного взаимодействия процессов применяется механизм отображения в память.

В этой главе рассматриваются методы IPC, основанные на использовании сообщений, разделяемой памяти, отображении в памяти и семафоров. В следующей главе описываются методы IPC, реализованные на основе применения интерфейса транспортного уровня и гнезд.

10.1. Методы IPC, соответствующие стандарту POSIX.Ib

Методы IPC определены не в POSIX. 1, а в POSIX.Ib, стандарте на переносимую операционную систему реального времени. В POSIX.Ib определены следующие методы IPC: сообщения, разделяемая память и семафоры. Хотя в POSIX.Ib эти методы и называются так же, как в UNIX System V, синтаксис их совершенно другой. Синтаксис изменен преднамеренно, поскольку методам UNIX System V присущи определенные недостатки:

В сообщениях, разделяемой памяти и семафорах UNIX System V в качестве идентификаторов (имен) используются целочисленные ключи. Вследствие этого создается пространство имен, отличное от пространства имен файлов, которые операционной системе нужно поддерживать.

Целочисленные ключи (идентификаторы) сообщений, разделяемой памяти и семафоров являются уникальными только в масштабах одного компьютера. По этой причине сетевые приложения не могут пользоваться названными методами IPC для межмашинного взаимодействия.

fСообщения, разделяемая память и семафоры UNIX System Vреализова-J ны в адресном пространстве ядра. Это означает, что при выполнении , каждой операции над этими IPC-объектами процессу приходится пере-V ключать контекст из пользовательского режима в режим ядра, что приводит к снижению производительности.

Для того чтобы избавиться от этих недостатков, сообщения, разделяемая память и семафоры в POSIX.Ib реализованы по-другому, а именно:

В сообщениях, разделяемой памяти и семафорах POSIX.Ib используются идентификаторы, похожие на имена файлов (скажем, /psx4 message), благодаря чему к IPC-объекту можно обращаться, как к любому файловому объекту, и никакое отдельное пространство имен поддержки со стороны ядра не требуется.

В случае использования уникальных имен в масштабе сети IPC-объекты могут поддерживать и межмашинное взаимодействие. Однако правила именования для реализации такого взаимодействия в POSIX.Ib не оговорены.

Методы IPC POSIX.Ib не требуют поддержки на уровне ядра, поэтому производители могут реализовать эти методы с помощью библиотечных функций. Более того, IPC-объекты создаются и обрабатываются в адресном пространстве процессов. Все это сводит к минимуму степень участия ядра и повышает эффективность IPC.

Следует отметить, что пока методы IPC поддерживаются в немногих к<шмерческих UNIX-системах, но в будущих версиях операционных систем такая поддержка наверняка будет предусмотрена.

В данной главе рассматриваются сообщения, разделяемая память и семафоры. Эти методы IPC применяются как в UNIX System V, так и в POSIX.Ib.

10.2. Методы IPC, применяющиеся в UNIX System V

UNIX System V поддерживает следующие методы IPC:

Сообщения. Позволяют процессам, работающим на одном компьютере, обмениваться форматированными данными.

Семафоры. Представляют собой набор общесистемных переменных, которые могут модифицироваться и использоваться процессами, запущенными на одном компьютере, для синхронизации их выполнения. Семафоры обьино используются (в сочетании с разделяемой памятью) для управления доступом к данным, находящимся в той или иной области разделяемой памяти.

Разделяемая память. Позволяет нескольким процессам, выполняемым на одной машине, совместно использовать общую область виртуальной памяти. При реализации этого метода процессы могут непосредственно читать и модифицировать записанные в разделяемую память данные.

Интерфейс транспортного уровня (ТЫ). Позволяет двум процессам, выполняемым на разных компьютерах, создать прямой двусторонний канал связи. В качестве базового интерфейса транспортировки данных в этом методе используется механизм STREAMS.

В UNIX System V.4, кроме того, поддерживаются BSD-гнезда. Поэтому приложения, ориентированные на использование гнезд, могут быть перенесены в эту систему с минимумом доработок.

10.3. Сообщения в UNIX System V

Метод межпроцессного взаимодействия на основе сообщений позволяет нескольким процессам, выполняемым на одной UNIX-машине, взаимодействовать между собой путем передачи и приема сообщений. Это равносильно организации в каком-либо здании центрального почтового ящика, в который люди могут опускать свою почту и забирать предназначенную для них корреспонденцию. Аналогию можно продолжить: так же, как на конверте каждого письма указан адрес получателя, у любого сообщения есть целочисленный идентификатор (тип), присваиваемый сообщению процессом-отправителем, благодаря чему процесс-получатель может избирательно принимать сообщения только нужных ему типов.

Метод, основанный на использовании сообщений, был предложен для того, чтобы устранить некоторые недостатки каналов (именованных и неименованных). Один из этих недостатков заключается в том, что к обеим