В описании монитора, как и в описании любой процедуры, включаются спецификация интерфейса монитора и, как минимум, описания процедур передачи в буфер, получения из буфера и инициализации буфера. То есть монитор – это модуль, в котором общие данные объединены вместе с множеством процедур, реализующих доступ к этим данным. Являясь конструктивами высокого уровня, сами мониторы не представляют средств синхронизации процессов, однако приобретают их благодаря применению рассмотренных примитивов синхронизации в процедурах, встроенных в монитор. В проектах современных параллельных языков программирования мониторы являются достаточно широко используемым механизмом взаимного исключения, что вытекает главным образом из модульной структуры монитора. Так как все обращения к общим данным должны выполняться с помощью мониторных процедур, становится возможным написать и отладить монитор отдельно от процессов, которые им будут пользоваться. При введении монитора в систему гарантируется целостность данных, которые он защищает. Правильность функционирования не может быть нарушена даже добавлением к системе процесса, содержащего ошибки. На этапе компиляции может быть проверена законность обращения к общим данным, построен граф доступов к системе и, в принципе, обнаружены возможные тупиковые ситуации.
Однако с понятием монитора возникли и весьма трудные проблемы.
Во-первых, для сохранения свойства взаимной исключаемости выходящий из монитора процесс может возобновить протекание лишь одного из следующих процессов. Это не позволяет синхронизировать несколько процессов с помощью одного процесса, управляющего синхронизацией.
Во-вторых,
проблема возникает в процедурах А
В, образующих иерархию
абстрактных типов данных. Если в результате вызова, например, из монитора А
некоторой процедуры, содержащейся в мониторе В, процесс выполнения этой
процедуры будет приостановлен и взаимное исключение освобождает процесс в В,
однако взаимное исключение не освобождает процесс в А, вызывая тупиковую
ситуацию.
И, наконец, монитор предназначался для защиты общей памяти, с которой работает много процессоров одновременно. В современных же вычислительных системах нет общей памяти, которая нуждалась бы в защите и к тому же локальная память каждого процессора представлена иерархией памятей различного быстродействия.
Наличие этих проблем и крайнее нежелание вводить примитивы низкого уровня типа семафоров, постоянно вызывало появление альтернативных подходов к проблеме взаимного исключения и синхронизации.
Во многих отношениях разработка механизмов взаимодействия между параллельными процессами первоначально находилась под влиянием однопроцессорной реализации многопроцессного программного обеспечения, в котором передача данных между процессами осуществлялась через области общей памяти. Это отражалось и в разрабатываемых языковых конструкциях высокого уровня для описания взаимодействия процессов. Как только взаимодействующие процессы в большинстве своем территориально разместились на разных процессорах, появились иные посредники на пути передачи и приема данных, которые принципиально отличались от общей памяти. Между каждой парой процессоров появилась возможность встроить отдельный физический канал связи, то есть создать некую фиксированную коммуникационную среду, в которую, как в область общей памяти, можно было бы заслать подготовленные кому-то данные, и ожидать, пока адресат не пожелает их оттуда забрать. Освобожденный после изъятия данных канал связи может теперь использоваться другой парой взаимодействующих процессов и, возможно, с другим логическим именем. Впервые активная модель взаимодействия, в которой передача данных и синхронизация рассматривались, как единое неразделяемое действие, была предложена Хоаром в конце 60-х годов. Эта модель базировалась на посылке сообщений о готовности передать данные одним процессом, например, А и готовности получить данные другим процессом, например, В.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.