Диссертация (1148255), страница 11
Текст из файла (страница 11)
Свойство не являетсянеразрывно связанным с другими свойствами модели и может быть из неё выделено.Таким образом, мы готовы предложить новую модель – усиленную модель консистентности по выходу (англ. enhanced release consistency). По сути,представляющую собой оригинальную модель консистентности по выходу, дополненную двумя свойствами из модели консистентности по входу:611. Наличие связи между общими и синхронизационными переменными.2. Разделение захватов на эксклюзивные и неэксклюзивные.Заметим, что модель ленивой консистентности по выходу (см.
раздел 1.4.6)можно представить аналогичным образом – как модель консистентности по выходу со свойством отложенной рассылки обновлений из модели консистентностипо входу.Опишем предложенную модель в виде совокупности требований:1. Любая переменная в общей памяти (ОП) проассоциирована с одной и только одной синхронизационной переменной (СП). Таким образом, каждойСП соответствует группа переменных в ОП (ГП ).2. Захват СП может быть эксклюзивным (разрешающим операции записив ГП ) и неэксклюзивным (разрешающим только чтение ГП ).3. Операция эксклюзивного захвата СП может быть завершена только после того, как все узлы освободят данную переменную (даже если она былазахвачена неэксклюзивно).4.
Операция захвата СП может быть завершена только после того, как всепредшествующие операции над ГП на всех узлах будут завершены.5. Доступ к ГП возможен только в случае нахождения СП на данном узлев захваченном состоянии.6. Операции захвата и освобождения СП должны подчиняться модели процессорной консистентности.Используя нотацию, введённую в разделе 1.4.1, схематично данную модельможно выразить рисунком 2.1, введя новые обозначения – () для входа в критическую секцию X (от англ. start) и () для выхода из неё (от англ. finish).При этом подразумевается, что синхронизационная переменная проассоциирована с общей переменной .621 : () ()1 ()2 ()2 :() ()2 ()3 :()1Рисунок 2.1 – Модель расширенной консистентности по выходуК сожалению, этот рисунок оказался бы справедлив и для модели консистентности по входу, так как консистентность обеспечивается тоже толькопосле входа в соответствующую критическую секцию (что видно на примерепроцессов 2 и 3 ).
Однако принципиальное отличие нашей модели в том, чтоона использует операции входа в секцию типа () не для того, чтобы начатьпоиск соответствующих данных в сети, а лишь для того, чтобы дождаться завершения их передачи в случае если передача к данному моменту еще не успелазавершиться.Далее мы покажем, что внесенные в модель новые свойства могут бытьреализованы способом, который не повлечет дополнительной нагрузки на конечного разработчика и не увеличит склонность конечного решения к ошибкампо невнимательности.
В ближайших же разделах сосредоточимся на воплощении принципов описанной модели в алгоритмах.2.2.2. Роли узлов и алгоритм смены ролиВсе узлы в МАКС DSM с точки зрения пользователя – равноправны. Укаждого есть доступ к общей памяти, и каждый может производить с ней операции, обмениваясь тем самым данными с другими узлами. Однако сохраняяравноправие на верхнем уровне (с точки зрения пользователя), внутри системы узлы могут выполнять различные функции, приобретая соответствующуюспециализацию.
Введем в систему роли, перечисленные в таблице 2.11 и далееопишем их назначение.Роль «Сервер» вводится с целью обеспечить максимальную надежность си1Сокращения в таблице образованы от английских слов new, server, backup, client соответственно.63Название Сокращение ОписаниеНовичокnewНовый узел, роль не определенаСерверsrvГлавный узел в системеКопияbckРезервная копия сервераКлиентclnОбычный узелТаблица 2.1 – Роли узлов в МАКС DSMстемы и простоту восстановления в случае сбоев. Здесь мы используем подходполной репликации данных, описанный в разделе 1.5.4. Данный подход требует выделения среди узлов особой роли – в англоязычной литературе эта рольизвестна как sequencer, мы же используем название «Сервер».Роль «Копия» необходима для быстрого восстановления Сервера, в случае его сбоя. Несмотря на то, что Сервер не обладает уникальными данными, алишь координирует работу остальных узлов, восстановление Сервера – задачаболее сложная и более продолжительная чем восстановление любого другогоузла.
Аналогично подходу, описанному в разделе 1.5.1, Копия будет «протоколировать» все операции Сервера, а в случае сбоя последнего, быстро возьмётна себя его функции.Роль «Клиент» введём для обозначения всех остальных узлов, не являющихся ни Сервером, ни Копией.И, наконец, роль «Новичок» – временное состояние узла в момент его возникновения.Так как МАКС DSM является динамической системой, роли узлов не могут быть фиксированными.
Для наглядности схема возможной смены ролейпредставлена на рисунке 2.2. Каждый узел потенциально может выполнять любую роль, а также менять её в процессе работы, за единственным исключением– оставив однажды роль Новичок, вернуться к этой роли узел уже не сможет1 .1Ситуации подобно перезагрузке узла мы рассматриваем как исчезновение узла и возникновение нового.64Условия, в которых узел можетclnизменить свою роль, выражены алгоритмом на рисунке 2.3. Для удобnewства, названия процедур отражают текущую роль узла. Значения переменsrvbckных 1 , 2 , 3 определяются низлежащим сетевым уровнем и зависят отсвойств конкретных каналов.1:2:3:4:5:6:7:8:9:10:11:12:13:14:15:16:17:18:Рисунок 2.2 – Схема возможных изменений ролей узла в МАКС DSMprocedure Новичокif продолжительность тишины в эфире > 1 thenроль ← Серверelse if у Сервера нет Копии thenроль ← Копияelseроль ← Клиентprocedure Клиентif продолжительность «молчания» Сервера > 2 thenроль ← Серверelse if сервер требует стать Копией thenроль ← Копияprocedure Копияif продолжительность «молчания» Сервера > 3 thenроль ← Серверprocedure Серверif нет Копии И есть Клиенты thenпотребовать от произвольного Клиента стать КопиейРисунок 2.3 – Алгоритм смены роли узлом в МАКС DSM◁ 3 > 2652.2.3.
Организация сообщений в типичных операциях системыВ разделе 2.2.2 мы сделали выбор, что пойдем по пути полной репликацииданных и определили роли узлов в будущей системе.Согласно принципам, изложенным в разделе 1.5.4, а также решению поддерживать копию Сервера, типичные операции в МАКС DSM будут выглядетьтак, как изображено на рисунке 2.4.Сервер2: сохранениеКопия11a1: запрос3: ок4: распространение24КлиентКлиент3КлиентРисунок 2.4 – Операция записи в МАКС DSMКлиент (узел №2) пытается выйти из критической секции, и соответствующая инструкция блокируется на время осуществления следующих действийсистемы:1.
Клиент отправляет запрос на Сервер.2. Сервер обращается к своей копии с целью сохранить информацию о запросе.3. Копия производит запрошенную операцию и сообщает об этом Серверу.4. Сервер оповещает все узлы системы, включая инициатора, об операции.Только по получении сообщения, соответствующего шагу 4, узел-инициатор может быть уверен, что операция произведена и разблокировать инструкцию выхода из критической секции, продолжив выполнение прикладного кода66в обычном режиме1 .Рассмотрим теперь действия узла при попытке входа в критическую секцию.
Так как поведение оказывается достаточно тривиальным, представим шаги только в виде списка (номера шагов не имеют отношения к предыдущемурисунку). Как и в прошлый раз, операции, обрамляющие данный алгоритм,опишем за пределами списка.Итак, Клиент пытается захватить определенную синхронизационную переменную (или, что то же самое, войти в критическую секцию) и блокируется.Управление передается механизму поддержки консистентности:1. Клиент отправляет запрос Серверу с обозначением своего желания и способа, которым он хочет осуществить захват (эксклюзивный или неэксклюзивный).2.
Сервер, в случае если переменная не числится уже захваченной кем-либоэксклюзивно, обращается к Копии, чтобы учесть данное действие. Еслиже уже имеется эксклюзивный захват данной переменной – Сервер просто ожидает её освобождения (Клиент в это время остаётся заблокированным).3. Копия, как обычно, учитывает происходящее и рапортует по завершениисвоих действий Серверу. При этом Копия не забывает сохранить информацию о том, какую именно переменную и в каком режиме захватил данныйузел.4. Сервер также запоминает информацию, описанную пунктом выше, послечего отправляет Клиенту сообщение с разрешением осуществить запрошенное действие.5.
Клиент разблокируется, входит в критическую секцию и осуществляет запланированную серию операций с общими переменными (в процессе чего1Разблокировка также возможна по таймауту, данная ситуация рассматривается в разделе ниже.67никаких сообщений во вне не отправляется). Затем Клиент пытается выйти из секции, чем вновь вызывает свою временную блокировку и вызовмеханизма, описанного ранее.2.2.4.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
