14.3. Распределенные взаимоисключения

Напомним, что в главах 5, "Параллельные вычисления: взаимоисключе­ния и многозадачность", и 6, "Взаимоблокировка и голодание", речь шла о во­просах, связанных с выполнением параллельных процессов. Двумя основными проблемами, которые возникают при этом, являются взаимоисключение и взаимоблокировка, В указанных главах основное внимание сосредоточено на решениях указанных проблем в контексте одной системы, обладающей одним или несколькими процессорами, но единой основной памятью. В распределен­ной операционной системе, управляющей системой с множеством процессоров, которые не используют совместно основную память или часы, возникают но­вые трудности и требуются новые решения. Алгоритмы взаимоисключения и взаимоблокировки должны зависеть от обмена сообщениями и не могут зави­сеть от возможности доступа к общей памяти. В этом разделе и далее взаимо­исключения и взаимоблокировка изучаются в контексте распределенной опе­рационной системы.

Концепции распределенных взаимоисключений

Если два или большее количество процессов соревнуются за возможность использования системных ресурсов, нужен механизм обеспечения взаимоис­ключений. Предположим, что двум или большему количеству процессов нужен доступ к единому неразделяемому ресурсу, например к принтеру. Во время своей работы каждый процесс будет отдавать команды этому устройству ввода-вывода, получая информацию о его состоянии, отправляя данные и/или полу­чая их. Такой ресурс мы будем называть критическим, а использующую его часть программы — критическим разделом программы. Важно отметить, что в каждый момент времени может выполняться критический раздел только одной программы. Понимание и воплощение этого ограничения не может основы­ваться лишь на операционной системе, так как точные требования могут быть не очевидными. Например, принтер должен находиться под управлением про­цесса до тех пор, пока не будет распечатан весь файл. В противном случае в распечатанном документе будут чередоваться строки, направленные разными конкурирующими процессами.

Чтобы успешно применять параллелизм процессов, нужно иметь возможность задавать критические разделы и реализовывать взаимоисключения. Это является ос­новой любой схемы параллельной обработки. Устройство или средство, обеспечи­вающее взаимоисключения, должно удовлетворять следующим требованиям.

1. Необходимо обеспечить реализацию взаимоисключения: в каждый момент времени лишь один процесс из всех тех, в которых имеются критические разделы одного и того же ресурса или совместно используемого объекта, может находиться в этом критическом разделе.

2. Если выполнение процесса прекращается не в критическом разделе, это не должно влиять на работу других процессов,

3. Нельзя, чтобы процесс, которому нужен доступ к критическому разделу, ожидал до бесконечности: нельзя допускать взаимоблокировок и голодания.

4. Если в критическом разделе нет ни одного процесса, то любой процесс, ко­торому нужно войти в этот критический раздел, должен иметь возможность сделать это без промедления.

5. Не делается никаких предположений об относительной скорости выполнения процессов или об их количестве.

6. Процесс остается в критическом разделе лишь в течение конечного времени.

На рис. 14.7 показана модель, на примере которой можно изучать раз­ные подходы к взаимоисключениям в контексте распределенных систем. До­пустим, что некоторое количество систем соединены между собой с помощью какого-то сетевого устройства. Предположим также, что в операционной сис­теме каждой системы имеется некоторая функция или процесс, отвечающий за распределение ресурсов. Каждый такой процесс управляет определенным количеством ресурсов и обслуживает несколько пользовательских процессов. Нужно разработать алгоритм, согласно которому эти процессы могут совме­стно обеспечивать взаимоисключение.

Механизм взаимоисключения может быть либо централизованным, либо распределенным. В полностью централизованном алгоритме один из узлов настраивается как управляющий; он управляет доступом ко всем совместно используемым объектам. Если какому-то процессу нужен доступ к критиче­скому ресурсу, он генерирует запрос и отправляет его своему локальному процессу, управляющему ресурсами. Локальный управляющий процесс, в свою очередь, передает этот запрос контрольному узлу, который возвращает ответ (разрешение), когда совместно используемый объект становится дос­тупным. Закончив работу с ресурсом, запрашивавший его процесс отправля­ет управляющему узлу сообщение об освобождении ресурса. Такой централи­зованный алгоритм обладает двумя определяющими свойствами.

1. Решения о распределении ресурсов принимает только управляющий узел.

2. Вся необходимая информация, включая сведения об идентификаторах и размещении всех ресурсов, а также о статусе распределения каждого ресурса, сосредоточена на управляющем узле.

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

Из-за этих, присущих централизованным алгоритмам, проблем, возрос ин­терес к разработке распределенных алгоритмов. Полностью распределенный ал­горитм обладает такими свойствами [МАЕК87].

1. Каждый узел в среднем обладает одинаковым количеством информации.

2. Каждый узел имеет лишь частичные сведения обо всей системе и может принимать решения, основываясь на этих сведениях.

3. За принятие конечного решения все узлы отвечают в равной мере.

4. На осуществление конечного решения все узлы в среднем затрачивают одинаковые усилия.

5. Отказ одного из узлов не приводит к упадку всей системы.

6. В системе нет общих часов, по которым можно координировать события.

Пункты 2 и 6 требуют некоторого уточнения. Что касается пункта 2, то в некоторых распределенных алгоритмах требуется, чтобы все узлы обменивались известной им информацией. Даже в этом случае в каждый фиксированный мо­мент времени некоторая часть информации находится в пути и может еще не дойти до всех остальных узлов. Таким образом, из-за временных задержек, воз­никающих при передаче сообщений, хранящаяся на каком-то отдельном узле информация не является полностью обновленной, и в этом смысле каждый узел обладает лишь частичной информацией.

Что касается пункта 6, из-за того, что обмен информацией между системами происходит с некоторой задержкой, невозможно поддерживать часы, которые были бы немедленно доступны для всех систем. Кроме того, с технической точки зрения непрактично поддерживать одни централизованные часы, по которым можно было бы точно синхронизовать все локальные часы. Однако через некото­рое время в показаниях разных локальных часов возникнет расхождение, в ре­зультате чего утратится синхронизация.

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

Упорядочение событий в распределенной системе

Основой работы большинства распределенных алгоритмов взаимоисклю­чений и взаимоблокировок является временное упорядочение событий. Основ­ным ограничением в нашей ситуации является отсутствие общих часов или средств синхронизации локальных часов. Проблему можно сформулировать и так: хотелось бы иметь возможность определить, какое из событий произошло раньше, — событие а в системе i или событие b в системе ). Кроме того, жела­тельно было бы иметь возможность делать такие выводы относительно любой системы, подключенной к сети. К сожалению, эта формулировка не является точной по двум причинам. Во-первых, между самим событием и его наблюде­нием в других системах может возникать задержка. Во-вторых, из-за отсутст­вия синхронизации возникают разногласия в показаниях часов, установленных в различных системах.

Чтобы преодолеть эти трудности, Лампорт (Lamport) [LAMP78J предложил метод, получивший название метода временных меток (timestamping), который помогает упорядочивать события в распределенных системах, не используя фи­зические часы. Эта технология оказалась настолько действенной и эффективной, что стала использоваться в подавляющем большинстве алгоритмов взаимоис­ключений и взаимоблокировок.

Для начала выберем определение понятия событие (event). В конечном сче­те, мы имеем дело с событиями, происходящими в локальной системе, например вхождением процесса в критический раздел или выходом из него. Однако в рас­пределенной системе процессы взаимодействуют между собой с помощью сооб­щений. Поэтому имеет смысл ассоциировать события с сообщениями. Связать локальное событие с сообщением очень просто — например, процесс может от­правлять сообщение, когда ему нужно войти в критический раздел или выйти из него. Чтобы избежать неоднозначности, события будем связывать только с от­правкой сообщений, а не с их получением. Таким образом, каждый раз, когда процесс передает сообщение, задается событие, соответствующее моменту време­ни, когда сообщение покинуло процесс.

Схема временных меток предназначена для того, чтобы упорядочить собы­тия, заключающиеся в передаче сообщений. В каждой подключенной к сети сис­теме i поддерживается локальный счетчик C_i, выполняющий функцию часов. Перед передачей каждого сообщения система увеличивает показания этого счет­чика на 1. Сообщение имеет вид

(m,T,i),

где т — содержимое сообщения, T, — временная метка сообщения, равная C_i, i — численный идентификатор узла.

Получив сообщение, система-адресат j устанавливает значение своего счет­чика равным увеличенному на единицу максимальному значению из текущего показания счетчика системы и поступившей временной метки:

С_j <- 1 + mах[С_j,T_i]

Упорядочение событий в каждом узле происходит по следующим правилам. Говорят, что сообщение х, поступившее от узла i, предшествует сообщению у, поступившему от узла j, если выполняется одно из следующих условий.

1. T_i < T_j

2. T_i = T_j и i < j.

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

Пример работы этого алгоритма показан на рис. 14.8. В распределенной системе имеется три узла, каждый из которых представлен процессом, выпол­няющим алгоритм временных меток. Процесс P₁ начинается с показанием ча­сов, равным 0. Перед передачей сообщения а он увеличивает показание своих часов на 1 и передает сообщение вида (а, 1,1), в котором первое численное зна­чение соответствует временной метке, а второе — идентификатору узла. Это сообщение принимается процессами на узлах 2 и 3. В обоих случаях показа­ния локальных часов равняются нулю, а после получения сообщения устанав­ливаются равными 2 = 1+ тах[0,1]. Процесс Р₂ генерирует следующее сооб­щение, увеличивая перед этим показание своих часов на 1 (т.е. до 3). Получив это сообщение, процессы 1 и 3 должны установить на своих часах значение 4. Затем примерно в одно и то же время процесс P₁ отправляет сообщение b, a процесс Р₃ — сообщение j. Оба сообщения имеют одинаковые временные мет­ки. Благодаря сформулированному выше временному принципу это не приве­дет к путанице. После всех этих событий упорядочение событий на всех узлах будет одним и тем же, а именно {а, х, b, j}.

Как показано на рис. 14.9, описанный алгоритм работает, несмотря на разли­чия во времени передачи сообщений в паре систем. Процессы P₁ и Р₄ отправляют со­общения с одинаковыми временными метками. Сообщение от процесса pi прибывает на узел 2 раньше, чем сообщение от процесса Р₄, а на узел 3 сообщения от этих про­цессов прибывают в обратном порядке. Несмотря на это, после получения всех сооб­щений их упорядочение на всех узлах остается одинаковым: {a, q}.

Заметим, что упорядочение по такой схеме не всегда соответствует реальной последовательности событий. Так как основой этих алгоритмов является схема временных меток, не важно, какое событие произошло первым на самом деле. Важно только то, что упорядочение всех процессов по этому алгоритму выпол­няется согласованно.

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

Распределенная очередь

Первая версия

Один из самых ранних подходов, предложенный для обеспечения распреде­ленных взаимоисключений, связан с концепцией распределенной очереди [LAMP78]. В основе этого алгоритма лежат такие предположения.

1. Распределенная система состоит из N узлов, пронумерованных числами от 1 до N. На каждом узле содержится один процесс, запрашивающий взаимоисклю­чающий доступ к ресурсам от имени других процессов; этот процесс также вы­ступает арбитром, разрешая перекрывающиеся во времени входящие запросы.

2. Получение сообщений, отправленных одним процессом другому, происходит в том же порядке, в котором эти сообщения были отправлены.

3. Каждое сообщение доставляется по указанному адресу в течение конечного времени.

4. Сеть является полносвязной; это означает, что каждый процесс может отправить сообщение любому другому процессу без участия в передаче какого-либо промежуточного процесса.

Условия 2 и 3 можно выполнить, применяя надежный транспортный про­токол, такой, как TCP.

Опишем алгоритм, предназначенный для того случая, когда каждый узел управляет только одним ресурсом. Обобщение на случай управления нескольки­ми ресурсами тривиально.

В этом алгоритме предпринята попытка обобщить простой алгоритм, кото­рый мог бы работать в централизованной системе. Если ресурсом управляет еди­ный центральный процесс, он может выстраивать поступающие запросы в оче­редь и предоставлять доступ к ресурсу в порядке поступления запросов. Чтобы реализовать этот же алгоритм в распределенной системе, на всех узлах должна быть копия одной и той же очереди. Чтобы порядок предоставления ресурса по запросам совпадал на всех узлах, можно применять временные метки. При этом возникает одна сложность: из-за того, что сообщение передается в течение како­го-то конечного времени, возникает угроза, что на двух различных узлах во гла­ве очереди будут находиться запросы разных процессов. Обратимся к рис. 14.9. Имеется некоторый интервал времени, в течение которого сообщение а уже по­лучено процессом Р₂, а сообщение q — процессом Р₃, но оба сообщения еще не дошли до других процессов, которым они также были отправлены. Таким обра­зом, в течение этого интервала времени процессы P₁ и Р₂ считают, что первым в очереди является сообщение а, а процессы Р₃ и Р₄ считают, что первым является сообщение q. Подобная ситуация может привести к нарушению требования взаимоисключения. Во избежание этого накладывается следующее ограничение: прежде чем процесс, исходя из состояния своей собственной очереди, примет решение о предоставлении ресурса, он должен получить от всех других узлов со­общение, гарантирующее, что в каналах не осталось ни одного сообщения, кото­рое может занять первое место в очереди.

На каждом узле поддерживается структура данных, в которой хранятся записи о последних сообщениях, полученных от каждого узла (а также о тех, которые недавно отправлены с данного узла). Лампорт называет такую структуру очередью; фактически она является массивом, в котором каждому узлу соответствует один элемент. В каждый момент времени в элементе ло­кального массива q[j] содержится сообщение от процесса Р_j. Массив инициа­лизируется следующим образом:

q[j] = (Release,0, j) j = 1,□ ,N

В этом алгоритме используются три вида сообщений:

- (Request, T_i, i): запрос ресурса процессом Р_i;

- (Reply, T_j, j): предоставление процессом Р_j доступа к ресурсу, который на­ходится под его управлением;

- (Release, T_k, k): процесс P_k, освобождает предоставленный ему ресурс.

Алгоритм работает следующим образом.

1. Когда процессу P_i нужен доступ к ресурсу, он отправляет запрос (Request, T_i, i) с временной меткой, значение которой равняется текущему показанию локального счетчика этого процесса. Процесс помещает это со­общение в элемент своего собственного массива q[i] и рассылает его всем ос­тальным процессам.

2. Когда процесс P_j получает запрос (Request, T_i, i), он помещает его в элемент собственного массива q[i]. Если в элементе q[j] не содержится сообщения с запросом, то процесс Р_j отправляет процессу Р_i ответ. Это именно то дейст­вие, с помощью которого реализуется описанное ранее правило. Оно гаран­тирует, что в момент принятия решения в каналах не осталось ни одного сообщения с запросом.

3. Процесс Р_i может получить доступ к ресурсу (войти в критический раздел), если соблюдаются два условия.

а. Запрос q, поступивший от процесса Р_i, является первым сообщением в собственной очереди этого процесса; поскольку сообщения на всех узлах упорядочены одинаково, это сообщение предоставляет в каждый момент времени доступ к ресурсу одному и только одному процессу.

б. Все другие сообщения, содержащиеся в локальном массиве, являются более поздними, чем сообщение в элементе q[i]; соблюдение этого правила гарантирует, что процессу Р_i известно обо всех запросах, предшествую­щих его текущему запросу.

4. Процесс Р_i освобождает ресурс путем генерации сообщения (Request, T_i, i). которое он помещает в свой собственный массив и рассылает всем другим процессам.

5. Получив сообщение (Request, T_i, j), процесс Р_i помещает его в элемент массива q[j], заменяя его текущее содержимое этим сообщением.

6. Получив сообщение (Reply, T_j, j), процесс Р_i помещает его в элемент массива q[j], заменяя его текущее содержимое этим сообщением.

Легко показать, что этот алгоритм обеспечивает взаимоисключение, равно­правность процессов, отсутствие взаимоблокировок и голодания.

- Взаимоисключение. Запросы на вход в критический раздел обрабатываются в том порядке, который определяется механизмом временных меток. Если процесс Р_i принимает решение войти в свой критический раздел, то в системе не может быть никаких других запросов, которые были переданы перед его запросом. Это утверждение является справедливым, так как процесс Р_i к этому моменту получил от всех других узлов сообщения, помеченные более поздним временем, чем его запрос. В этом можно быть уверенным благодаря механизму ответных сообщений. Напомним, что при передаче сообщений их порядок не может быть нарушен.

- Равноправность. Доступ по запросам предоставляется строго в соответствии с временными метками. Поэтому все процессы обладают равными возможностями.

- Отсутствие взаимоблокировок. Благодаря тому, что порядок временных меток на всех узлах совпадает, взаимоблокировки невозможны.

- Отсутствие голодания. Как только процесс Р_i закончит выполнение своего критического раздела, он передает сообщение об освобождении (Release). Это приводит к удалению на всех узлах запроса, поступившего от процесса Р_i, и предоставлению доступа к критическому разделу другому процессу.

Чтобы оценить эффективность работы этого алгоритма, отметим, что для обес­печения исключения необходимо переслать Зх (N - 1) сообщений: (N - 1) сообщений-запросов, (N - 1) ответных сообщений и (N - 1) сообщений об освобождении.

Вторая версия

В [RICA81] предложен улучшенный вариант алгоритма Лампорта. В нем предпринята попытка оптимизировать первоначальную версию этого алгоритма, исключив из него сообщения об освобождении ресурса. Остаются в силе все ра­нее сделанные предположения, за исключением того, что теперь нам не нужно, чтобы сообщения, отправленные одним процессом другому, приходили в том же порядке, в котором они были отправлены.

Как и ранее, на каждом узле имеется один процесс, управляющий распре­делением ресурсов. Этот процесс поддерживает массив q и работает по следую­щим правилам.

1. Если процессу Р_i нужен доступ к ресурсу, он генерирует запрос (Request, T_i, i) с временной меткой, значение которой равняется текущему показанию локального счетчика этого процесса. Процесс помещает это сообщение в элемент своего собственного массива q[i] и рассылает его всем остальным процессам.

2. Когда процесс Р_j получает запрос (Request, T_i, i), он действует следующим образом.

а. Если процесс Р_j в данное время находится в своем критическом разделе, он откладывает отправку ответного сообщения (см. правило 4 ниже).

б. Если процесс Р_j не ожидает, пока ему можно будет войти в свой критиче­ский раздел (у него нет необработанных запросов), он передает процессу P_i ответ (Reply, T_j, j).

в. Если процесс Р_j ожидает, пока ему можно будет войти в свой критиче­ский раздел, и если входящее сообщение следует после запроса процесса Р_j, то он помещает это сообщение в элемент собственного массива q[i] и откладывает отправку ответного сообщения.

г. Если процесс Р_j ожидает, пока ему можно будет войти в свой критический раздел, и если входящее сообщение предшествует запросу процесса Р_j, то он помещает это сообщение в элемент собственного массива q[i] и отправляет процессу P_i ответное сообщение (Reply, T_j, j).

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

4. После выхода из своего критического ресурса процесс Р_i освобождает ре­сурс, рассылая ответные сообщения на все ожидающие запросы.

Диаграмма переходов каждого процесса из одного состояния в другое пока­зана на рис. 14.10.

Итак, если процессу нужно войти в свой критический раздел, он рассылает всем другим процессам запрос с временной меткой. Когда он получит ответы от всех них, он сможет войти в свой критический раздел. Если процесс получает запрос от другого процесса, он, в конце концов, должен отправить ему соответствующий ответ. Если процессу не нужно входить в свой критический раздел, он отправляет этот от­вет сразу же. Если же ему нужно войти в свой критический раздел, то он сравнивает временные метки своего запроса и запроса, полученного от другого процесса. Если временная метка запроса другого процесса является более поздней, отправка ответа откладывается; в противном случае ответ отправляется тут же.

При соблюдении этого метода требуется 2x(N - 1) сообщений: (N - 1) сооб­щений-запросов нужны для того, чтобы указать на намерение процесса P_i войти в свой критический раздел, и еще (N - 1) ответных сообщений — чтобы предос­тавить запрашиваемый доступ.

Использование временных меток в этом алгоритме обеспечивает взаимоис­ключение; благодаря ему удается также избежать взаимоблокировок. Докажем последнее утверждение методом от противного: предположим, что возможна си­туация, когда в каналах не осталось ни одного сообщения, каждый процесс от­правил запрос и не получил необходимого ответа. Такая ситуация невозможна, потому что решение о задержке ответа основывается на порядке поступления за­просов. Поэтому найдется хотя бы один запрос с минимальным значением вре­менной метки, который получит все необходимые ответы. Благодаря этому взаимоблокировка невозможна.

Кроме того, поскольку запросы упорядочены, голодания также удается из­бежать. Так как запросы обслуживаются именно в порядке их расположения, каждый процесс рано или поздно становится самым старым и будет обслужен.

Подход с передачей маркера

Несколько исследователей предложили реализовать взаимоисключения с помощью совершенно иного подхода, в котором используется передача маркера между процессами. Маркер — это объект, который в каждый момент времени может содержаться только в одном процессе. Процесс, в котором находится маркер, может войти в критический раздел без дополнительного разрешения. Покидая свой критический раздел, процесс передает маркер другому процессу.

В этом разделе описана одна из наиболее эффективных схем. Впервые она была предложена в [SUZU82]; логически эквивалентное ей предложение можно найти в [RICA83]. Согласно этому алгоритму нужны две структуры данных. Маркер, который передается от одного процесса другому, на самом деле являет­ся массивом, в k-м элементе которого записана временная метка, соответствую­щая времени, когда маркер побывал в процессе Р_k. Кроме того, каждый процесс поддерживает массив запросов, в j-м элементе которого записана временная мет­ка, соответствующая моменту получения запроса от процесса Р_j.

Процедура состоит в следующем. Первоначально маркер присваивается одному из процессов, который выбирается произвольным образом. Процесс, которому нужно использовать свой критический раздел, может это сделать, если он владеет марке­ром; в противном случае процесс рассылает всем другим процессам запрос с времен­ной меткой и ждет, пока один из них не пришлет ему маркер. Покинув свой крити­ческий раздел, процесс Р_j должен передать маркер какому-то другому процессу. Вы­бор этого процесса происходит следующим образом. Процесс Р_j просматривает массив запросов в следующем порядке: j + 1, j + 2, ..., 1, 2, ..., j — 1, пока не найдет первый элемент [k], в котором временная метка последнего запроса больше, чем k-e значение маркера (запрос[k] > маркер[k]). Это означает, что процесс P_k сделал запрос после последнего пребывания в нем маркера.

В листинге 14.1 приведен алгоритм, состоящий из двух частей. Первая свя­зана с использованием критического раздела и состоит из вступления, критиче­ского раздела и заключительной части. Вторая часть касается действий, пред­принимаемых после получения запроса. Переменная clock — это локальный счетчик, используемый для временных меток. Выполнение функции wait (access, token) приводит к ожиданию процесса до тех пор, пока не будет получено сообщение типа "доступ", которое затем помещается в массив token.

Для работы алгоритма требуется следующее количество сообщений:

- N сообщений (N - 1 сообщений для рассылки запроса и 1 сообщение для получения маркера), если запрашивающий процесс не содержит маркера;

- ни одного сообщения, если маркер находится в этом процессе.

Листинг 14.1. Алгоритм с передачей маркера (для процесса Р_i)

if (!token_present) /* Вступительная часть */

{

clock++;

broadcast (Request, clock, i);

wait (access, token);

token_present = true;

}

token_held = true;

<критический раздел>;

/* Заключительная часть */

token[i] = clock;

token_held = false;

for (int j = i + 1; j < n; j++)

{

if {request(j) > token [j] && token_present)

{

token_present = false;

send (access, token [j]) ;

}

}

for (j = 1; j <= i-l; j++)

{

if (request(j) > token [j] && token_present)

{

token_present = false;

send (access, token [j]);

}

}

а) Первая часть

if (received (Request, k, j))

{

request (j) = max(request(j), k) ;

if (token_present && !token_held)

<код заключительной части>;

}

б) Вторая часть

Примечание

send (j, access, token) отправляет процессом j сообщения

access с маркером

broadcast(request, рассылает сгенерированное

clock, i) процессом i сообщение с запросом

и временной меткой всем другим

процессам

received (request, t, j) принимает от процесса j

сообщение с запросом и временной

меткой t