2014-02-09
1051
Очереди сообщений
Очереди сообщений (queue) являются более сложным методом связи между взаимодействующими процессами по сравнению с каналами. С помощью очередей также можно из одной или нескольких задач независимым образом посылать сообщения некоторой задаче-приемнику. При этом только процесс-приемник может читать и удалять сообщения из очереди, а процессы-клиенты имеют право лишь помещать в очередь свои сообщения. Таким образом, очередь работает в одном направлении. Если необходима двухсторонняя связь, то можно создать две очереди.
Отличия работы с очередями от работы с конвейерами:
· очереди предоставляют возможность использовать несколько дисциплин обработки сообщений:
o FIFO – сообщение, записанное первым, будет первым и прочитано;
o LIFO – сообщение, записанное последним, будет прочитано первым:
o приоритетный – сообщения читаются с учетом их приоритета;
o произвольный доступ, т.е. можно читать любое сообщение, тогда как конвейер обеспечивает только дисциплину FIFO.
|
|
|
· при чтении сообщения из конвейера оно из него удаляется. При чтении из очереди этого не происходит, сообщение при желании может быть прочитано несколько раз;
· в очередях присутствуют не непосредственно сами сообщения, а только их адреса в памяти и размер.
Каждый процесс, использующий очередь, должен предварительно получить разрешение на использование общего сегмента памяти с помощью системных запросов API (application program interface).
При организации параллельного выполнения нескольких процессов одной из главных функций ОС является решение сложной задачи корректного распределения ресурсов между выполняющимися процессами и обеспечение последних средствами взаимной синхронизации и обмена данными.
При параллельном исполнении процессов могут возникать ситуации, при которых два или более процессов все время находятся в заблокированном состоянии. Самым простым является случай, когда каждый из двух процессов ожидает ресурс, занятый другим процессом. Эта тупиковая ситуация называется дедлоком (dead lock –смертельное объятие), тупиком или клинчем. Тупики чаще всего возникают из-за конкуренции несвязанных параллельных процессов за ресурсы вычислительной системы, но иногда к тупикам приводят и ошибки программирования.
Рассмотрим пример, поясняющий причину возникновения тупиков.
Пусть имеются три процесса ПР1, ПР2, ПР3, которые вырабатывают соответственно сообщения М1, М2, М3. Пусть процесс ПР1 является «потребителем» сообщения М3, процесс ПР2 получает сообщение М1, а ПР3 – сообщение М2 от процесса ПР2, то есть каждый из процессов является и «поставщиком» и «потребителем» одновременно и вместе они образуют «кольцевую» систему передачи сообщений через почтовые ящики (ПЯ) – рис.1.
|
|
|
Рис.1. Кольцевая схема взаимодействия процессов
Если процедуры в каждом процессе выполняются в следующем порядке:
ПР1: …
Послать сообщение (ПР2, М1, ПЯ2);
Ждать сообщение (ПР3, М3, ПЯ1);
…
ПР2: …
Послать сообщение (ПР3, М2, ПЯ3);
Ждать сообщение (ПР1, М1, ПЯ2);
…
ПР3: …
Послать сообщение (ПР1, М3, ПЯ1);
Ждать сообщение (ПР2, М2, ПЯ3);
…,
то никаких трудностей не возникает. Однако перестановка этих двух процедур в каждом из процессов (Ждать….;Послать….;) вызывает тупик. В самом деле, в этом случае ни один из процессов не может послать сообщения до тех пор, пока сам его не получит, а этого события никогда не произойдет, поскольку ни один процесс не может этого сделать.
Проблема борьбы с тупиками становится все более актуальной и сложной по мере развития и внедрения параллельных систем. Борьба с тупиковыми ситуациями основывается на одной из трех стратегий:
· предотвращение тупика;
· обход тупика;
· распознавание тупика с последующим восстановлением.
