Добавлен: 29.10.2018
Просмотров: 48162
Скачиваний: 190
646
Глава 8. Многопроцессорные системы
тики совместного использования файлов. Вместо требования к read видеть эффект
всех предыдущих вызовов write можно ввести новое правило: «Изменения, вносимые
в открытый файл, сначала видны только производящему их процессу. Другие процессы
видят эти изменения только после закрытия файла». Следование этому правилу не
изменит случившееся на рис. 8.34, б, но теперь то, как ведут себя процессы (процесс B
получает исходную версию файла), будет узаконено. Когда клиент 1 закрывает файл,
он посылает на сервер измененную копию файла, поэтому при последующих систем-
ных вызовах read будут, как и требовалось, получены новые версии файла. По сути,
это модель загрузки-выгрузки, показанная на рис. 8.32. Данное семантическое правило
нашло широкое применение и известно как сеансовая семантика (session semantics).
При использовании сеансовой семантики возникает вопрос о том, что произойдет, если
два или более клиента одновременно прочитают в кэш и модифицируют один и тот
же файл. Одно из решений состоит в том, чтобы согласиться с тем, что поскольку все
файлы закрываются поочередно и их версии отправляются назад на сервер, окончатель-
ный результат будет зависеть от того, какая из версий будет закрыта последней. Менее
приятной, но немного более простой в реализации альтернативой будет согласиться
с тем, что окончательным результатом станет один из вариантов, но не оговаривать при
этом конкретный выбор.
Альтернативный подход к сеансовой семантике заключается в использовании модели
загрузки-выгрузки, но с автоматической блокировкой загруженного файла. Попытки
других клиентов загрузить файл будут пресекаться до тех пор, пока первый клиент не
вернет этот файл. Если файл пользуется большим спросом, сервер может послать со-
общение клиенту, удерживающему файл, с просьбой поторопиться, хотя эта просьба
может ни к чему не привести. В конечном счете, правильное выстраивание семантики
совместного использования файлов — дело непростое, не имеющее изящных и эффек-
тивных решений.
8.3.5. Связующее программное обеспечение,
основанное на объектах
Давайте теперь рассмотрим третью парадигму. Вместо того чтобы утверждать, что все
относится к документам или все относится к файлам, мы скажем, что все относится
к объектам. Объект (object) — это коллекция взаимосвязанных переменных с набором
процедур доступа, называемых методами (methods). Непосредственный доступ про-
цессов к переменным запрещен. Он заменен для них вызовами методов.
Некоторые языки программирования, к примеру C++ и Java, являются объектно-
ориентированными, но они имеют дело с объектами на уровне языка, а не с объектами
времени исполнения. Одной из хорошо известных систем, основанных на объектах
времени исполнения, является CORBA (Common Object Request Broker Architecture —
общая архитектура посредников запросов к объектам) (Vinoski, 1997). CORBA являет-
ся клиент-серверной системой, в которой клиентские процессы на клиентских машинах
могут вызывать операции над объектами, размещенными на серверных машинах (воз-
можно, удаленных). CORBA была разработана для разнородной системы, работающей
на множестве аппаратных платформ и операционных систем и программируемой на
множестве языков. Чтобы клиент, работающий на одной платформе, мог вызвать
сервер, работающий на другой платформе, между клиентом и сервером вставляются
посредники, ORB (Object Request Broker — посредник запросов к объектам). Посред-
8.4. Распределенные системы
647
ники ORB играют в архитектуре CORBA весьма важную роль, о чем говорит даже то,
что эта аббревиатура дала название самой системе.
Описание каждого CORBA-объекта дается на языке определения интерфейса IDL
(Interface Definition Language) и сообщает об экспортируемых объектом методах
и ожидаемых каждым из методов типах параметров. Спецификация IDL может быть
откомпилирована в клиентскую процедуру-заглушку и хранится в библиотеке. Если
клиентскому процессу заранее известно, что ему потребуется доступ к определенному
объекту, этот объект компонуется вместе с объектным кодом клиентской заглушки.
Спецификация IDL также может быть откомпилирована в скелетную (skeleton)
про цедуру, используемую на серверной стороне. Если заранее нельзя сказать, какие
объекты CORBA понадобятся процессу, возможно также применение динамического
вызова, описание работы которого выходит за рамки данной книги.
При создании объекта CORBA создается также ссылка на этот объект, которая воз-
вращается создавшему объект процессу. В дальнейшем процесс обращается к методам
созданного объекта по этой ссылке. Ссылка может быть передана другим процессам
или сохранена в объектной библиотеке.
Чтобы вызвать метод объекта, клиентский процесс сначала должен получить ссылку
на этот объект. Ссылку можно получить либо непосредственно от создавшего объект
процесса, либо, что более вероятно, путем поиска ее по имени или по функции в каком-
нибудь каталоге. Когда доступна ссылка на объект, клиентский процесс упорядочивает
параметры вызываемого метода в подходящую структуру, а затем связывается с кли-
ентским ORB-посредником. Тот в свою очередь отправляет сообщение серверному
ORB-посреднику, который вызывает метод объекта. Весь механизм схож с вызовом
удаленной процедуры RPC.
Задача ORB-посредников состоит в том, чтобы скрыть все низкоуровневые подроб-
ности распределения и связи от программ клиента и сервера. В частности, ORB-
посредники скрывают от клиента, где находится сервер, что на нем работает — двоичная
программа или сценарий, на каком оборудовании и под управлением какой операци-
онной системы он работает, активен ли объект в настоящий момент и как два ORB-
посредника обмениваются данными (посредством TCP/IP, RPC, общей памяти и т. д.).
В первой версии системы CORBA протокол обмена между клиентским и серверным
ORB-посредниками не был определен, в результате чего каждый производитель ORB-
посредников использовал собственный протокол и продукты двух разных произво-
дителей не могли общаться друг с другом. Протокол был определен в версии 2.0. Для
связи через Интернет используется протокол, называемый IIOP (Internet InterORB
Protocol — протокол для связи между ORB-посредниками по Интернету).
Чтобы получить возможность использования в CORBA-системах объектов, которые
специально под них не создавались, каждый объект может быть оснащен адаптером
объекта
(object adapter). Это оболочка, занимающаяся такими рутинными операциями,
как регистрирование объекта, генерирование ссылок на объект и активация объекта,
если он вызывается из неактивного состояния. Расположение всех этих составных
частей CORBA показано на рис. 8.35.
Серьезная проблема CORBA заключается в том, что каждый объект находится только
на одном сервере, то есть производительность объектов, интенсивно используемых на
клиентских машинах, разбросанных по всему миру, будет ужасно низкой. На практике
CORBA приемлемо работает только в небольших по масштабу системах, связывающих
процессы на одном компьютере, в одной локальной сети или в пределах одной компании.
648
Глава 8. Многопроцессорные системы
Рис. 8.35. Основные элементы распределенной системы на основе CORBA
(части CORBA закрашены серым цветом)
8.3.6. Связующее программное обеспечение,
основанное на взаимодействии
Последняя из рассматриваемых парадигм для распределенной системы называется
связующим программным обеспечением,
основанным на взаимодействии. Она будет
рассмотрена на примере системы Linda (академический научно-исследовательский
проект, давший начало целой области исследований).
Linda
представляет собой оригинальную систему связи и синхронизации, разработан-
ную в Йельском университете Дэвидом Гелернтером и его студентом Ником Каррьеро
(Carriero and Gelernter, 1986; Carriero and Gelernter, 1989; Gelernter, 1985). В системе
Linda независимые процессы общаются через абстрактное пространство кортежей. Это
пространство является глобальным для всей системы, и процессы на любой машине
могут вставлять кортежи в пространство кортежей или удалять их из него независимо
от того, как и где эти кортежи хранятся. Для пользователя пространство кортежей вы-
глядит как большая глобальная общая память, уже встречавшаяся ранее в различных
формах (например, на рис. 8.21, в).
Кортеж
похож на структуру в C или Java. Он состоит из одного или нескольких полей,
каждое из которых является значением некоторого типа, поддерживаемого базовым
языком. (Система Linda реализуется с помощью добавления библиотеки к стандарт-
ному языку, например к C.) В системе C-Linda типы полей включают целые числа,
длинные целые числа, числа с плавающей запятой, а также составные типы, такие как
массивы (включая строки) и структуры (но не другие кортежи). В отличие от объектов
кортежи представляют собой просто данные и не содержат никаких связанных с ними
методов. В листинге 8.1 показаны три примера кортежей.
Листинг 8.1. Три кортежа в системе Linda
("abc", 2, 5)
("matrix-1", 1, 6, 3.14)
("family", "is-sister", "Stephany", "Roberta")
Предусмотрено проведение с кортежами четырех операций. Первая операция, out, по-
мещает кортеж в пространство кортежей. Например,
out("abc", 2, 5);
8.4. Распределенные системы
649
помещает кортеж («abc», 2, 5) в пространство кортежей. Полями операции out, как
правило, являются константы, переменные или выражения, как в следующей опе-
рации:
out("matrix−1", i, j, 3.14);
которая помещает в пространство кортежей кортеж из четырех полей, второе и третье
из которых определяются текущими значениями переменных i и j.
Извлечение кортежей из пространства кортежей осуществляется с помощью при-
митива in. Адресование кортежей осуществляется по их содержимому, а не по имени
или адресу. Поля в in могут быть выражениями или формальными параметрами. Рас-
смотрим, к примеру, следующую операцию:
in("abc", 2, ?i);
Эта операция производит в пространстве кортежей поиск кортежа, содержащего строку
«abc”, целое число 2 и третье поле, содержащее любое целое число (предполагая, что
i — целое число). Если кортеж будет найден, он удаляется из пространства кортежей
и переменной i присваивается значение третьего поля. Подбор соответствия и уда-
ление являются атомарными операциями, поэтому если два процесса одновременно
выполняют одну и ту же операцию in, только один из них добьется успеха, если только
не найдутся два или более соответствующих кортежа. Пространство кортежей может
даже содержать несколько копий одного и того же кортежа.
В операции in используется простой алгоритм подбора соответствия. Поля в прими-
тиве in, называемые шаблоном (template), сравниваются (концептуально) с соответ-
ствующими полями каждого кортежа в пространстве кортежей. Подбор соответствия
считается успешным, если соблюдаются следующие три условия:
1. У шаблона и кортежа одинаковое количество полей.
2. Типы соответствующих полей совпадают.
3. Каждая константа или переменная в шаблоне соответствует своему полю в кор-
теже.
Формальные параметры, помеченные знаком вопроса, за которым следует имя или
тип переменной, не участвуют в сравнении (сравнивается только тип), но тем из них,
которые содержат имя переменной, после успешного завершения операции поиска
присваивается соответствующее значение.
Если соответствующего кортежа в пространстве кортежей нет, то вызывавший опе-
рацию процесс приостанавливается до тех пор, пока другой процесс не поместит
в пространство кортежей нужный кортеж, после чего вызывавший операцию процесс
автоматически возобновляется и получает новый кортеж. Автоматическая блокировка
и разблокирование процесса означают, что если один процесс собирается вставить кор-
теж, а другой — его извлечь, то не имеет значения, какой из них будет первым. Разница
заключается только в том, что если операция in осуществляется до операции out, будет
небольшая задержка, пока кортеж не станет доступен для извлечения.
Факт блокировки процесса при отсутствии необходимого ему кортежа может использо-
ваться по-разному. Например, с помощью этого свойства можно реализовать семафоры.
Чтобы создать семафор или выполнить операцию up на семафоре S, процесс может
вызвать следующий примитив:
out("semaphore S");
650
Глава 8. Многопроцессорные системы
Для выполнения операции down он вызывает следующий примитив:
in("semaphore S");
Состояние семафора S определяется количеством кортежей («semaphore S») в про-
странстве кортежей. Если таких кортежей нет, то любая попытка его получения будет
заблокирована до тех пор, пока какой-нибудь другой процесс не предоставит такой
кортеж.
Вдобавок к операциям out и in в системе Linda имеется примитив read, который анало-
гичен примитиву in, за исключением того, что он не удаляет кортеж из пространства
кортежей. Есть также примитив eval, который проводит параллельное вычисление
своих параметров и помещает получившийся кортеж в пространство кортежей. Этот
механизм может быть использован для выполнения произвольных вычислений. Имен-
но так в системе Linda создаются параллельные процессы.
Публикация-подписка
Следующий пример модели, основанной на взаимодействии, был создан под влиянием
системы Linda и назван публикацией-подпиской (publish/subscribe) (Oki et al., 1993).
Эта модель состоит из нескольких процессов, соединенных сетью распространения.
Каждый процесс может быть производителем информации, потребителем информации
или и тем и другим.
Когда у производителя информации есть новая порция информации (например, новые
биржевые сводки), он распространяет ее всем по сети в виде кортежа. Это действие
называется публикацией (publishing). Каждый кортеж содержит иерархически струк-
турированную строку темы публикации с полями, разделенными точками. Процес-
сы, интересующиеся определенной информацией, могут подписаться (subscribe) на
конкретные темы, при этом в строке темы могут использоваться групповые символы
(wildcards). Подписка осуществляется путем сообщения фоновому процессу кортежей
(демону), работающему на той же машине и отслеживающему публикуемые кортежи,
какие темы нужно искать.
Реализация модели публикации-подписки показана на рис. 8.36. Когда у процесса есть
кортеж для публикации, он распространяет его по локальной сети. Демон кортежей на
каждой машине копирует все распространяемые подобным образом кортежи в свою
оперативную память. Затем он просматривает строку темы сообщения, чтобы опреде-
лить заинтересованные в нем процессы, пересылая каждому такому процессу копию
полученного сообщения. Кортежи также могут распространяться по глобальным сетям
или Интернету. Для этого в каждой локальной сети одна машина должна исполнять
роль информационного маршрутизатора, собирая все опубликованные кортежи и пере-
сылая их другим локальным сетям, реализуя, таким образом, дальнейшее распростра-
нение. Эта пересылка может осуществляться разумным образом, пересылая кортеж
только тем удаленным локальным сетям, в которых имеется хотя бы один подписчик,
заинтересованный в этом кортеже. Для этого информационные маршрутизаторы долж-
ны обмениваться информацией о подписчиках.
В данной модели могут быть реализованы различные типы семантики, включая на-
дежную доставку и гарантированную доставку, даже в условиях возникновения сбоев.
В последнем случае старые кортежи необходимо хранить на тот случай, если они позже
понадобятся. Один из способов их хранения предусматривает подключение системы