Параллельное и распределенное программирование на С++

• Агенты, реализованные как объекты, отличающиеся узкой специализацией, требуют собственных адресных пространств, поскольку они запускаются как отдельные процессы.

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

• Объекты реализованы в SPMD- или МРМП-архитектуре, рассчитанной на использование параллельного программирования, причем эти объекты расположены в различных процессах и на различных компьютерах.

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

• Деко м позиция задачи и ее решения на м ножество объектов, приче м некоторые из них будут принадлежать рааличным процесса м и раз м ещаться на разных компьютерах.

• Обеспечение связи между объектами, принадлежащими различным процесса м (адресным пространствам).

• Синхронизация взаимодействия между локальны м и и удаленны м и объектами.

• Обработка ошибок и исключений в распределенной среде.

Декомпозиция задачи и инкапсуляция ее решения

Проектирование объектно-ориентированного программного обеспечения — это процесс перевода требований к ПО в проект, в котором с помощью объектов моделируется каждый аспект разрабатываемой системы и выполняемой ею работы. Центральное место в этом проекте отводится структуре и иерархии коллекций объектов, а также их взаимоотношениям и взаимодействиям. Для поддержки понятия модели ПО в С++ используется ключевое слово class. Существует два базовых типа моделей. Первый тип модели — масштабированное представление некоторого процесса, концепции или идеи. Этот тип модели используется для анализа или экспериментирования. Например, класс применяется для разработки модели молекулы, т.е. с помощью концепции С++-класса можно смоделировать гипотетическую структуру некоторого химического процесса, происходящего в молекулах. Программным путем можно затем изучить поведение молекулы при внедрении новых групп атомов. Второй тип модели ПО — воспроизведение некоторой реальной задачи, процесса или идеи. Цель этой модели — заставить некоторую часть системы ПО или приложения функционировать подобно ее «прототипу». В этом случае ПО занимает место некоторого компонента или некоторого физического предмета в неавтоматизированной системе. Например, мы можем использовать концепцию класса для моделирования калькулятора. При корректном моделировании всех его характеристик и поведения можно создать экземпляр этого класса и использовать в качестве настоящего калькулятора. Программный калькулятор здесь будет играть роль реального калькулятора. Таким образом, смоделированный нами класс может служить в качестве виртуального лублера некоторого реального лица, места, предмета или идеи. Главное в программной модели — ухватить суть реального предмета.

Декомпозиция (decomposition) — это процесс разделения задачи и ее решения на ряд подзадач, коллекций объектов и принципов взаимоотношений между этими объектами. Аналогично инкапсуляция (encapsulation) — это моделирование характеристик, атрибутов и поведения некоторого лица, места, предмета или идеи с помощью С++-конструкции class. Такое моделирование (инкапсуляция) и декомпозиция являются частью этапа проектирования объектно-ориентированного ПО. Объектно-ориентированные приложения, которые содержат распределенные объекты, вносят в процесс проектирования дополнительный уровень сложности. С точки зрения «чистого» проектирования местоположение объектов в приложении не должно влиять на разработку атрибутов и характеристик этих объектов. Класс — это модель и, если местоположение не является частью этой модели, то даже самое «крайнее» расположение объектов (экземпляров этого класса) не должно иметь значение. Однако объекты существуют не в вакууме. Они взаимодействуют и обмениваются информацией с другими объектами. Если объекты (участники взаимодействия) расположены на разных компьютерах, и, возможно, даже в различных сетях, то оказывается, что фактор местоположения объектов необходимо с самого начала включать в процесс проектирования ПО. И хотя насчет того, на каком именно этапе проектирования следует рассматривать этот фактор, специалисты существенно расходятся во мнениях, тем не менее все единолушны в том, что его необходимо рассматривать. Дело в том, что обработка ошибок и исключений при взаимодействии объектов, расположенных в различных процессах или на различных компьютерах, отличается от обработки ошибок и исключений при взаимодействии объектов одного и того же процесса. Кроме того, связи и взаимодействия между объектами одного процесса реализуются совершенно не так, как при расположении объектов в различных процессах, которые могут выполняться на разных компьютерах. Это нужно иметь в виду еще на раннем этапе проектирования. В распределенном объектно-ориентированном приложении вся его работа делится между объектами и реализуется в виде функций-членов различных объектов. Объекты должны быть логически разделены согласно определенной модели декомпозиции работ (Work Breakdown Model — WBM). Они могут быть разделены согласно моделям типа «клиентс - сервер», «изготовитель-потребитель», равноправных узлов, «классной доски» или мультиагентной системы. Логическая структура каждой такой модели (с особенностями распределения объектов) показана на рис. 8.1.

Во всех моделях, показанных на рис. 8.1, предполагается, что объекты могут быть на одном и том же или на разных компьютерах (главное — они принадлежат разным процессам). Уже сам факт принадлежности рааличным процессам делает объекты распределенными ^[13]. Все модели представляют рааличные подходы к распределению работы приложения между объектами.

Взаимодействие между распределенными объектами

Рис.8.1. Логическая структура и распределение объектов в моделях «изготовитель-потребитель», равноправных узлов, «классной доски» и мультиагентной системы

Если объекты относятся к одному и тому же процессу, то в качестве средств межобъектно г о «общения» можно использовать механизм передачи параметров, вызовы обычных методов и использование г лобальных переменных. Если объекты принадлежат различным процессам, выполняемым на одном компьютере, то средствами ком м уникации между объекта м и м огут служить файлы, каналы, очереди c дисциплиной обслуживания «первы м пришел — первы м обслужен», разделяе м ал па м ять, буферы об м ена или пере м енные среды. Если же объекты «прописаны» на различных компьютерах, то в качестве средств связи придется использовать сокеты, вызовы удаленных процелур и дру г ие типы средств сетево г о про г раммирования. При это м мы должны поду м ать не только о то м, как булут общаться объекты в распределенном приложении, но и о том, посредство м че г о будет реализовано это об щ ение. Объектно- ориентированные приложения могут включать как простые типы данных, так и довольно сложные, а именно классы, определенные пользователем. Такие классы часто используются для связи между объектами. Поэтому связь между распределенными объектами будет обеспечиваться не только с помощью простых встроенных типов данных (например int, float или double), но и посредством классовых типов, определенных пользователем, без которых некоторые объекты не смогут выполнить свою работу. Кроме того, необходимо позаботиться о том, чтобы у одних объектов была возможность вызывать методы других объектов, расположенных в других адресных пространствах. Более того, необходимо прелусмотреть возможность для одного объекта «знать» о методах удаленных объектов. В то время как язык С++ поддерживает средства объектно-ориентированного программирования, в нем не предусмотрено никаких встроенных средств по обеспечению связи между распределенными объектами. Он не содержит никаких встроенных методов для локализации удаленных объектов и формирования к ним запросов.

Для реализации связи между распределенными объектами разработан ряд протоколов. Двумя наиболее важными из них являются IIOP (Internet Inter-ORB Protocol — протокол, определяющий передачу сообщений между сетевыми объектами по TCP/IP) и RMI (Remote Method Invocation — вызов удаленных методов). С помощью этих протоколов могут общаться объекты, расположенные практически в любом мести сети. В этой главе мы рассмотрим методы реализации распределенных объектно-ориентированных программ с использованием упомянутых протоколов и спецификации CORBA (Common Object Request BrokerArchitecture). Спецификация CORBA представляет собой промышленный стандарт для определения отношений, взаимодействий и связей между распределенными объектами. IIOP и GIOP — два основных протокола, с которыми работает спецификация CORBA. Эти протоколы хорошо согласуются с протоколом TCP/IP. CORBA — самый простой и наиболее гибкий способ добавления средств распределенного программирования в среду С++. Средства, предоставляемые спецификацией CORBA, реализуют поддержку двух основных моделей объектно-ориентированного параллелизма, которые мы используем в этой книге: «классная доска» и мультиагентные системы. Поскольку спецификация CORBA отражает принципы объектно-ориентированного программирования, с ее помощью можно реализовать приложения довольного широкого диапазона: от миниатюрных до очень больших. В этой книге мы используем MICO ^[14] — открытую реализацию спецификации CORBA. MICO-реализация поддерживает основные CORBA-компоненты и службы. С++ взаимодействует с MICO посредством коллекции классов и библиотек классов. Спецификация CORBA поддерживает распределенное объектно-ориентированное моделирование на каждом его уровне.

Синхронизация взаимодействия локальных и удаленных объектов

Для синхронизации доступа к данным и ресурсам со стороны нескольких объектов, принадлежащих различным процессам, но расположенных на одном компьютере, можно использовать мьютексы и семафоры, поскольку каждый процесс, хотя и отделенный от других, все же получает доступ к системной памяти компьютера. Эту системную память функционально можно рассматривать как разновидность памяти, разделяемой между процессами. Но если процессы распределены между различными компьютерами, то следует помнить, что разные компьютеры не имеют никакой общей памяти, и поэтому схемы синхронизации в этом случае должны быть реализованы по-другому. Синхронизация доступа (в зависимости от используемой WBM-модели) может потребовать интенсивного взаимодействия между распределенными объектами. Поэтому мы расширим традиционные методы синхронизации с помощью коммуникационных возможностей спецификации CORBA.

Обработка ошибок и исключений в распределенной среде

Возможно, одной из самых сложных областей обработки исключительных ситуаций или ошибок в распределенной среде считается область частичных отказов. В распределенной системе могут отказать один или несколько компонентов, в то время как другие компоненты будут функционировать в «предположении», что в системе все в полном порядке. Если такая ситуация (например, отказ одной функции) возникает в локальном приложении, т.е. когда все компоненты принадлежат одному и тому же процессу, об этом нетрудно уведомить все приложение в целом. Но для распределенных приложений все обстоит иначе. На одном компьютере может отказать сетевая карта, а объекты, выполняемые на других компьютерах, могут вообще не «узнать» о том, что где-то в системе произошел отказ. Что случится, если один из объектов попытается связаться с другим объектом и вдруг окажется, что сетевые связи с ним оборвались? Если при использовании модели равноправных узлов (в которой мы формируем различные группы объектов по принципу решения различных аспектов проблемы) одна из групп откажет, то как об этом отказе «узнают» другие группы? Более того, какое поведение мы должны «навязать» системе в такой сигуации? Должен ли отказ одного компонента приводить к отказу всей системы? Если даст сбой один клиент, то должны ли мы прекратить работу сервера? А если откажет сервер, то нужно ли останавливать клиент? А что, если сервер или клиенты продемонстрируют лишь частичные отказы? Поэтому в распределенной системе, помимо «гонок» данных и взаимоблокировок, мы должны также найти способы справляться с частичными отказами компонентов. И снова-таки подчеркиваем, важно найти распределенный подход к С++-механизму обработки исключительных сигуаций. Для начала нас удовлетво-рятвозможности, предоставляемые спецификацией CORBA.

Доступ к объектам из других адресных пространств

Объекты, разделяющие одну область действия (видимости), могут взаимодействовать, получал доступ друг к другу по именам, псевдонимам или с помощью указателей. Объект доступен только в случае, если «видимо» его имя или указатель на него. Видимость имен объектов определяется областью действия. С++ рааличает четыре основ-ныхуровня областей действия:

• блока;