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

*
1. Организация межпроцессного взаимодействия в ОС.
В чем же состоят принципиальные отличия в понятиях
«процесс» и «поток»?
В операционных системах, где существуют и процессы, и потоки,
процесс рассматривается операционной системой как заявка на
потребление всех видов ресурсов, кроме одного — процессорного
времени. Этот последний важнейший ресурс распределяется
операционной системой между другими единицами работы —
потоками, которые и получили свое название благодаря тому, что
они представляют собой последовательности (потоки выполнения)
команд.
1. Организация межпроцессного взаимодействия в ОС.
В идеальной многозадачной системе все процессы,
выполняющиеся параллельно, независимы друг от
друга (т.е., асинхронны).
На практике такая ситуация маловероятна, поскольку
рано или поздно возникают ситуации, когда
параллельным процессам необходим доступ к
некоторым общим ресурсам.
1. Организация межпроцессного взаимодействия в ОС.
При выполнении параллельных процессов может
возникать проблема, когда каждый процесс,
обращающийся к разделяемым данным, исключает для
всех других процессов возможность одновременного с
ним обращения к этим данным - это называется
взаимоисключением (mutual exclusion).
Ресурс, который допускает обслуживание только одного
пользователя за один раз, называется критическим
ресурсом. Если несколько процессов хотят
пользоваться критическим ресурсом в режиме
разделения времени, им следует синхронизировать
свои действия таким образом, чтобы этот ресурс всегда
находился в распоряжении не более чем одного их них.
1. Организация межпроцессного взаимодействия в ОС.
Для организации коммуникации между одновременно
работающими процессами применяются средства
межпроцессного взаимодействия (Interprocess
Communication - IPC).
Выделяются три уровня средств IPC:
• локальный;
• удаленный;
• высокоуровневый.
1. Организация межпроцессного взаимодействия в ОС.
Средства локального уровня IPC привязаны к
процессору и возможны только в пределах компьютера.
К этому виду IPC принадлежат практически все
основные механизмы IPC UNIX, а именно, каналы,
разделяемая память и очереди сообщений.
Коммуникационное пространство этих IPC,
поддерживаются только в пределах локальной системы.
Из-за этих ограничений для них могут реализовываться
более простые и более быстрые интерфейсы.
1. Организация межпроцессного взаимодействия в ОС.
Удаленные IPC предоставляют механизмы, которые
обеспечивают взаимодействие как в пределах одного
процессора, так и между программами на различных
процессорах, соединенных через сеть.
Сюда относятся удаленные вызовы процедур (Remote
Procedure Calls - RPC), сокеты Unix, а также TLI
(Transport Layer Interface - интерфейс транспортного
уровня) фирмы Sun.
1. Организация межпроцессного взаимодействия в ОС.
Под высокоуровневыми IPC обычно подразумеваются
пакеты программного обеспечения, которые реализуют
промежуточный слой между системной платформой и
приложением.
Эти пакеты предназначены для переноса уже
испытанных протоколов коммуникации приложения на
более новую архитектуру.
Об этих механизмах можно прочитать:
http://www.opennet.ru/docs/RUS/linux_parallel/node102.html
1. Организация межпроцессного взаимодействия в ОС.
Таблица методов IPC
Метод
Файл
Сигнал
Сокет
Канал
Именованный канал
Семафор
Разделяемая память
Обмен сообщениями
(без разделения)
Проецируемый в память файл
Очередь сообщений
Почтовый ящик
Реализуется (операционной системой или
другим окружением)
Все операционные системы.
Большинство операционных систем; некоторые
системы, как например, Windows, только
реализуют сигналы в библиотеке запуска Си, но не
обеспечивают их полноценной поддержки для
использования методов IPC.
Большинство операционных систем.
Все системы, соответствующие POSIX.
Все системы, соответствующие POSIX.
Все системы, соответствующие POSIX.
Все системы, соответствующие POSIX.
Используется в парадигме MPI, Java RMI, CORBA и
других.
Все системы, соответствующие POSIX; несет риск
появления состояния гонки в случае
использования временного файла. Windows также
поддерживает эту технологию, но использует API
отличный от POSIX.
Большинство операционных систем.
Некоторые операционные системы.
1. Организация межпроцессного взаимодействия в ОС.
Эти примитивы используются, чтобы исключить
одновременное пребывание двух процессов в их
критических областях, то есть для предотвращения
ситуации, приводящей к хаосу.
Процесс может находиться:
• в работающем,
• готовом к работе,
• в заблокированном состоянии
и может изменять состояние, когда он сам или другие
процессы задействуют один из примитивов
взаимодействия процессов.
Взаимодействие потоков имеет сходный характер.
1. Организация межпроцессного взаимодействия в ОС.
Примитивы взаимодействия процессов могут
использоваться для решения таких задач, как:
• производитель-потребитель,
• обедающие философы,
• читатель-писатель.
1. Организация межпроцессного взаимодействия в ОС.
Задача «производитель-потребитель» (ролик)
Каналы (Конвейер)
Канал (pipe) представляет собой средство связи
стандартного вывода одного процесса со стандартным
вводом другого. Каналы старейший из инструментов
IPC, существующий приблизительно со времени
появления самых ранних версий оперативной системы
UNIX.
Для реализации IPC возможно использование
полудуплексных и/или именованных каналов (FIFO).
1. Организация межпроцессного взаимодействия в ОС.
Задача «обедающие философы» (Дейкстра 1965 год)
1. Организация межпроцессного взаимодействия в ОС.
Задача «обедающие философы» (Дейкстра 1965 год)
Жизнь философа состоит из чередующихся
периодов приема пищи и размышлений.
Когда философ становится голоден, он старается
поочередно в любом порядке завладеть правой и
левой вилкой. Если ему удастся взять две вилки, он
на некоторое время приступает к еде, затем кладет
обе вилки на стол и продолжает размышления.
Основной вопрос состоит в следующем:
можно ли написать программу для каждого
философа, который действует предполагаемым
образом и никогда при этом не попадает в
состояние зависания?
1. Организация межпроцессного взаимодействия в ОС.
Задача «обедающие философы» (Дейкстра 1965 год)
Вариант 1
Философ (процесс) берет левую вилку, а затем
правую.
Ситуация
Допустим, что все пять философов (процессов)
одновременно берут левую от себя вилку.
Тогда никто из них не сможет взять правую вилку,
что приведет к взаимной блокировке.
Вывод
Решение ошибочное
1. Организация межпроцессного взаимодействия в ОС.
Задача «обедающие философы» (Дейкстра 1965 год)
Вариант 2
Философ (процесс) берет левую вилку, затем
проверяет доступность правой. Если эта вилка
недоступна, философ кладет на место левую вилку,
ожидает какое-то время, а затем повторяет весь
процесс.
Ситуация
При некоторой доле невезения все философы могут
приступить к выполнению алгоритма одновременно,
взяв левые вилки и увидев, что правые вилки
недоступны, опять одновременно положить на
место левые вилки, и так до бесконечности.
Вывод
Подобная ситуация, при которой все программы бесконечно работают, но не
могут добиться никакого прогресса, называется голоданием, или
зависанием процесса.
1. Организация межпроцессного взаимодействия в ОС.
Задача «обедающие философы» (Дейкстра 1965 год)
Вариант 3
Философ (процесс) берет левую вилку, затем
проверяет доступность правой. Если эта вилка
недоступна, философ кладет на место левую вилку,
а затем повторяет весь процесс по истечению
случайного момента времени.
Вывод
Шансы, что все будут топтаться на месте хотя бы в течение часа, будут очень
малы. Но возможны!
Так работает передача данных в популярной локальной сети Ethernet, когда
два компьютера одновременно отправляют пакет данных (возникает
коллизия), каждый из компьютеров выжидает случайный отрезок времени, а
затем повторяет попытку.
1. Организация межпроцессного взаимодействия в ОС.
Задача «обедающие философы» (Дейкстра 1965 год)
Вариант 4
Вывод
Можно внести улучшение, позволяющее избежать
взаимной блокировки и зависания. Для этого нужно
защитить 5 философов одним двоичным
семафором.
Перед тем как брать вилку философ переводит
семафор в состояние «занято», берет одну и вторую
вилку. А после того, как он положит вилки на
место, он должен выполнить перевод семафора в
состояние «свободен».
В момент «занятости» семафора никто не
предпринимает попытки взять вилку.
С теоретической точки зрения это вполне достаточное решение. Но с
практической в нем не учтен вопрос производительности:
в каждый момент времени может есть спагетти только один философ. А при
наличии пяти вилок одновременно могут есть спагетти два философа.
1. Организация межпроцессного взаимодействия в ОС.
Двоичные семафоры (Мьютексы) — это простейшие двоичные
семафоры, которые могут находиться в одном из двух состояний —
отмеченном или неотмеченном (открыт и закрыт соответственно). Когда
какой-либо поток, принадлежащий любому процессу, становится
владельцем объекта mutex, последний переводится в неотмеченное
состояние. Если задача освобождает мьютекс, его состояние становится
отмеченным.
Задача мьютекса — защита объекта от доступа к нему других потоков,
отличных от того, который завладел мьютексом. В каждый конкретный
момент только один поток может владеть объектом, защищённым
мьютексом. Если другому потоку будет нужен доступ к переменной,
защищённой мьютексом, то этот поток засыпает до тех пор, пока
мьютекс не будет освобождён.
Мьютекс отличается от семафора общего вида тем, что только
владеющий им поток может его освободить, т.е. перевести в
отмеченное состояние.
1. Организация межпроцессного взаимодействия в ОС.
Задача «обедающие философы» (Дейкстра 1965 год)
Вариант 5
Используется массив семафоров, по одному
семафору на каждого философа, в котором
отслеживается, чем занимается философ: ест,
размышляет или пытается поесть (пытается взять
вилки). Перейти в состояние приема пищи философ
может, только если в этом состоянии не находится
ни один из его соседей.
Вывод
Решение не вызывает взаимной блокировки и допускает максимум
параллелизма для произвольного числа философов.
1. Организация межпроцессного взаимодействия в ОС.
Задача «читатель-писатель» (Куртуа и др.1971 год)
Пример.
Система бронирования авиабилетов.
Есть множество соревнующихся процессов, желающих
обратиться к базе данных по чтению и записи.
Вполне допустимо наличие нескольких процессов,
одновременно считывающих информацию из базы
данных, но если один процесс обновляет базу данных
(проводит операцию записи), никакой другой процесс
не может получить доступ к базе данных даже для
чтения информации.
1. Организация межпроцессного взаимодействия в ОС.
Задача «читатель-писатель» (Куртуа и др.1971 год)
В этом решении первый читатель для получения
доступа к базе данных выполняет в отношении
семафора db операцию «занято». А все следующие
читатели просто увеличивают значение счетчика гс. Как
только читатель прекращают свою работу,
он уменьшает значение счетчика, а последний из
читателей выполняет в отношении семафора db
операцию «свободно», позволяя заблокированному
писателю, если таковой имеется, приступить к работе.
1. Организация межпроцессного взаимодействия в ОС.
Задача «читатель-писатель» (Куртуа и др.1971 год)
Ситуация
Допустим, что какой-то читатель уже использует базу
данных, и тут появляется писатель. Он может не
получить доступ к базе данных, поскольку писатели
должны иметь к базе данных исключительный доступ,
поэтому писатель приостанавливает свою работу Позже
появляются и другие читатели. Доступ дополнительным
читателям будет открыт до тех пор, пока будет
активен хотя бы один читатель. Писатель будет
приостановлен до тех пор, пока не останется ни одного
читателя.
Если новый читатель будет прибывать, каждые 2 с, и
каждый читатель затрачивает на свою работу по 5 с,
писатель доступа никогда не дождется.
1. Организация межпроцессного взаимодействия в ОС.
Задача «читатель-писатель» (Куртуа и др.1971 год)
Ситуация
Чтобы предотвратить такую ситуацию, программу
можно слегка изменить: когда писатель находится в
состоянии ожидания, то вновь прибывающий читатель
не получает немедленного доступа, а приостанавливает
свою работу и встает в очередь за писателем. При этом
писатель должен переждать окончания работы тех
читателей, которые были активны при его прибытии, и
не должен пережидать тех читателей, которые
прибывают уже после него. Недостаток этого решения
заключается в снижении производительности за счет
меньших показателей параллельности в работе.
1. Организация межпроцессного взаимодействия в ОС.
Сигналы
Сигналы являются программными прерываниями,
которые посылаются процессу, когда случается
некоторое событие.
Сигналы могут возникать синхронно с ошибкой в приложении, например
SIGFPE (ошибка вычислений с плавающей запятой) и SIGSEGV (ошибка
адресации), но большинство сигналов является асинхронными.
Сигналы могут посылаться процессу, если система обнаруживает
программное событие, например, когда пользователь дает команду
прервать или остановить выполнение, или получен сигнал на завершение
от другого процесса.
Сигналы могут прийти непосредственно от ядра ОС, когда возникает сбой
аппаратных средств ЭВМ. Система определяет набор сигналов, которые
могут быть отправлены процессу. При этом каждый сигнал имеет
целочисленное значение и приводит к строго определенным действиям.
1. Организация межпроцессного взаимодействия в ОС.
Сигналы
Сигналы являются программными прерываниями,
которые посылаются процессу, когда случается
некоторое событие.
Отдельные сигналы подразделяются на три класса:
• системные сигналы (ошибка аппаратуры, системная
ошибка и т.д.);
• сигналы от устройств;
• сигналы, определенные пользователем.
1. Организация межпроцессного взаимодействия в ОС.
Сигналы
Механизм передачи сигналов состоит из следующих
частей:
• установление и обозначение сигналов в форме
целочисленных значений;
• маркер в строке таблицы процессов для прибывших
сигналов;
• таблица с адресами функций, которые определяют
реакцию на прибывающие сигналы.
Как только сигнал приходит, он отмечается записью в таблице процессов.
Если этот сигнал предназначен для процесса, то по таблице указателей
функций в структуре описания процесса выясняется, как нужно
реагировать на этот сигнал. При этом номер сигнала служит индексом
таблицы.
1. Организация межпроцессного взаимодействия в ОС.
Сигналы
Известно три варианта реакции на сигналы:
• вызов собственной функции обработки;
• игнорирование сигнала (не работает для SIGKILL);
• использование предварительно установленной
функции обработки по умолчанию.
Чтобы реагировать на разные сигналы, необходимо
знать концепции их обработки. Процесс должен
организовать так называемый обработчик сигнала в
случае его прихода.
1. Организация межпроцессного взаимодействия в ОС.
Разделяемая память
Разделяемая память может быть наилучшим образом
описана как отображение участка (сегмента) памяти,
которая будет разделена между более чем одним
процессом.
Это гораздо более быстрая форма IPC, потому что здесь
нет никакого посредничества (т.е. каналов и т.п.).
Вместо этого, информация отображается
непосредственно из сегмента памяти в адресное
пространство вызывающего процесса. Сегмент может
быть создан одним процессом и впоследствии
использован для чтения/записи любым количеством
процессов.
1. Организация межпроцессного взаимодействия в ОС.
Отображение файла в память (на память) —
это такой способ работы с файлами в некоторых операционных
системах, при котором всему файлу или некоторой непрерывной
части этого файла ставится в соответствие определённый участок
памяти (диапазон адресов оперативной памяти). При этом чтение
данных из этих адресов фактически приводит к чтению данных из
отображенного файла, а запись данных по этим адресам приводит
к записи этих данных в файл.
1. Организация межпроцессного взаимодействия в ОС.
Отображение файла в память (на память)
Например.
В 32-разрядной Windows под "памятью" подразумевается не только
оперативная память (ОЗУ), но также и память, резервируемая
операционной системой на жестком диске. Этот вид памяти
называется виртуальной памятью. Код и данные отображаются на
жесткий диск посредством страничной системы (paging system)
подкачки. Страничная система использует для отображения
страничный файл (win386.swp в Windows 95/98 и pagefile.sys в
Windows NT). Необходимый фрагмент виртуальной памяти
переносится из страничного файла в ОЗУ и, таким образом,
становится доступным.
1. Организация межпроцессного взаимодействия в ОС.
Отображение файла в память (на память)
Альтернативой отображению может служить прямое чтение файла
или запись в файл. Такой способ работы менее удобен по
следующим причинам:
• Необходимо постоянно помнить текущую позицию файла и
вовремя её передвигать на нужное место, в которое
необходимо записать или из которого необходимо прочитать.
• Каждый вызов смены/чтения текущей позиции,
записи/чтения — это системный вызов, который приводит к
потере времени.
• Для работы через чтение/запись всё равно приходится
выделять буферы определённого размера, таким образом, в
общем виде работа состоит из трёх этапов: чтение в буфер ->
модификация данных в буфере -> запись в файл. При
отображении же работа состоит только из одного этапа:
модификация данных в определённой области памяти.
1. Организация межпроцессного взаимодействия в ОС.
Отображение файла в память (на память)
Дополнительным преимуществом использования отображения
является меньшая по сравнению с чтением/записью нагрузка на
операционную систему.
При использовании отображений операционная система не
загружает в память сразу весь файл, а делает это по мере
необходимости, блоками размером со страницу памяти (как
правило 4 килобайта). Таким образом, даже имея небольшое
количество физической памяти (например 32 мегабайта), можно
легко отобразить файл размером 100 мегабайт или больше, и при
этом для системы это не приведет к большим накладным
расходам.
Также выигрыш происходит и при записи из памяти на диск: если
вы обновили большое количество данных в памяти, они могут быть
одновременно (за один проход головки над диском) сброшены на
диск.
1. Организация межпроцессного взаимодействия в ОС.
Отображение файла в память (на память)
Наиболее общий случай, когда применяется отображение файлов
на память — загрузка процесса в память (это справедливо и для
Microsoft Windows и для Unix-подобных систем).
После запуска процесса операционная система отображает его
файл на память, для которой разрешено выполнение (атрибут
executable). Большинство систем, использующих отображение
файлов используют методику загрузка страницы по первому
требованию, при которой файл загружается в память не целиком, а
небольшими частями, размером со страницу памяти, при этом
страница загружается только тогда, когда она действительно
нужна.
В случае с исполняемыми файлами такая методика позволяет
операционной системе держать в памяти только те части
машинного кода, которые реально нужны для выполнения
программы.
2. Классические проблемы межпроцессного взаимодействия.
Синхронный доступ. Если все процессы считывают
данные из файла, то в большинстве случае проблем не
возникает. Однако, при попытке одним из процессов
изменить этот файл, могут возникнуть так называемые
конкурентные ситуации (race conditions).
2. Классические проблемы межпроцессного взаимодействия.
Дисциплина доступа. Если нужно, чтобы как можно
большее количество пользователей могли записывать
данные, организуется так называемая очередь (по
правилу «один пишет, несколько читают»). Практически
организуется две очереди: одна - для чтения, другая для записи. Такую дисциплину доступа можно
организовать с помощью барьеров (блокировок). При
этом создается общий барьер для считывателей, так
как несколько процессов могут одновременно
считывать данные, а также отдельный барьер для
процесса-писателя. Такая организация предотвращает
взаимные помехи в работе.
2. Классические проблемы межпроцессного взаимодействия.
Голодание процессов. Организация дисциплины
доступа может привести к ситуации, когда процесс
будет длительно ждать своей очереди для записи
данных. Поэтому иногда нужно организовывать очереди
с приоритетами.
2. Классические проблемы межпроцессного взаимодействия.
Управление потоком. Если нельзя точно определить,
какой из процессов запрашивает или возвращает свои
данные в нужный компьютер первым, используется так
называемое взаимодействие по модели "клиентсервер". При этом используются один или несколько
клиентов и один сервер. Клиент посылает запрос
серверу, а сервер отвечает на него. После этого клиент
должен дождаться ответа сервера, чтобы продолжать
дальнейшее взаимодействие. Такое поведение
называется управлением потоком. При одновременном
доступе здесь также могут использоваться очереди с
приоритетами.
2. Классические проблемы межпроцессного взаимодействия.
Тупик (deadlock). Классический тупик возникает, если
процесс A получает доступ к файлу A и ждет
освобождения файла B. Одновременно процесс B,
получив доступ к файлу B, ждет освобождения файла A.
Оба процесса теперь ждут освобождения ресурсов
другого процесса и не освобождают при этом
собственный файл.