Параллельное и распределенное программирование на С++
Шрифт:
S = (AC + DE + FBH)
часто называют логическим выражением, или булевым. Это выражение означает, что для пребывания системы в устойчивом состоянии (т.е. ее надежной работы) необходимо успешное выполнение одной из следующих групп задач: (А и С) или (D и E) или (F и В и H). По диаграмме событий нетрудно также понять, какие комбинации отказов компонентов могут привести к отказу системы. Например, если откажут только компоненты E и F, то система успешно отработает, если при этом «не подвелут» компоненты А и С. Но если бы дали сбой компоненты А, D и H, то систему в этом случае уже ничего бы не спасло от отказа. Диаграмма событий и логическое выражение — это очень полезные средства для описания параллельных зависимых и независимых компонентов, а также для построения схемы действия обработчика исключительных ситуаций. Например, используя диаграмму событий (см. рис. 7.6), мы можем наметить следующий подход к обработке исключений для нашего примера:
try{
start(task А and В)
} catch(mysterious_condition &E) {
try{
if(!(А && В)){
start(F and
}
} catch(mysterious_condition &E){
start(D and E)
}
};
Этот вид стратегии призван улучшить надежность системы. Слелует также отметить, что параллельно выполняемые программные компоненты и альтернативные варианты для планирования безотказной работы системы можно отобразить с помощью традиционной логической схемы, показанной на рис. 7.7.
Рис. 7.7. Логическая диаграмма, отображающая три И-схемы, объединяемые с помощью ИЛИ-схемы, для успешного завершения работы системы
Итак, на рис. 7.7 показано три И-схемы, объединяемые на основе ИЛИ-отношений для получения результата S (который означает успешное завершение работы системы). Диаграмма событий (см. рис. 7.6) и логическая схема (см. рис. 7.7) — это примеры простых методов, которые можно использовать для визуализации критических путей (ветвей) и критических компонентов в некоторой части ПО. После идентификации критических путей и компонентов разработчик должен прелусмотреть ответные действия, которые должна выполнить система в случае, если откажет любой из критических компонентов. Если при этом используется модель завершения, то обработчик исключений не делает попытку возобновить выполнение ПО с точки, в которой возникла исключительная ситуация. Вместо этого осуществляется выход из функции или процедуры, в которой произошло исключение, и предпринимаются действия по пе-револу системы в стабильное (насколько это возможно) состояние. Но если используется модель возобновления, то корректируются условия, создавшие аномалию, и программа возобновляется с точки, в которой возникла исключительнал ситуация. Важно отметить, что при реализации модели возобновления возможны определенные трудности. Например, предположим, что наш код содержит слелующую последовательность вложенных вызовов процедур:
try{
А вызывает В
В вызывает С
С вызывает D
D вызывает E
E сталкивается с аномалией, с которой не может справиться
}
catch(exception Q) {
}
Если в процелуре E возникла аномалия и было сгенерировано исключение, то возможна проблема со стеком вызовов. Нужно также решить вопрос с разрушением объектов и проблему «подвешенных» значений, возвращаемых процедурами. Подумайте, что произойдет, если процедуры С и D являются рекурсивными? Даже если мы откорректируем условие, вызвавшее исключение в процедуре E, то как вернуть программу в состояние, в котором она пребывала непосредственно перед выбросом исключения? А ведь мы должны сохранить информацию в стеке, таблицы создания и разрушения объектов, таблицы прерываний и пр. Это потребует больших затрат и обеспечения сложного взаимодействия между вызывающими и вызываемыми сторонами. Bce вышесказанное обозначило лишь поверхностный слой трудностей. Из-за сложности реализации модели возобновления и благодаря тому факту, что разработка больших систем может обойтись без нее, для С++ была выбрана модель завершения. В книге [44] Страуструп дает полное обоснование того, почему комитет ANSI в конце концов выбрал для механизма обработки исключений модель завершения. Но если, несмотря на то что модель возобновления действительно сопряжена с большими трудностями, надежность и бесперебойность ПО являются критичными факторами, то лля реализации этой модели все же имеет смысл приложить соответствующие усилия. При этом стоит иметь в виду, что С++-средства обработки исключений можно использовать и для реализации модели возобновления.
Резюме
Создание надежного ПО — серьезное занятие. К вопросам обработки исключительных ситуаций и исправления ошибок следует подходить с особой ответственностью. Тщательное тестирование и отладка каждого компонента ПО должны быть основными средствами защиты от программных дефектов. Обработку исключений необходимо внести в систему или подсистему ПО после того, как оно прошло этап строжайшего тестирования. Механизм генерирования исключений не следует использовать в качестве общего правила для обработки ошибок, поскольку он нарушает обычный ход выполнения программы. К средствам генерирования исключений следует прибегать только после того, как будут исчерпаны все остальные меры. Программист, который планирует проектировать более полные и полезные (с его точки зрения) классы исключений, должен использовать стандартные классы обработки исключений в качестве архитектурных «дорожных карт». Стандартные классы, не специализированные с помощью наследования, могут лишь уведомлять об ошибках. Можно создать более полезные классы исключений, которые бы обладали корректирующими функциями и большей информативностью. В общем случае, как модель завершения, так и модель возобновления позволяют продолжать выполнение программы. Обе эти модели предлагают альтернативу простому прерыванию программы при обнаружении ошибки. Более полное рассмотрение темы обработки исключительных ситуаций можно найти в работе [44].
Распределенное объектно-ориентированное программирование
Итак,
Распределенные объекты — это объекты, которые являются частью одного приложения, но размещены в различных адресных пространствах Адресные пространства могут относиться к одному или различным компьютерам, связанным сетью или другими средствами коммуникации. Объекты, включенные в приложение, могли быть изначально нацелены на совместную работу или разрабатываться различными отделами, подразделениями, компаниями или организациями в различное время и с разными целями. В категорию распределенных объектно-ориентированных приложений мотут попадать приложения из большого диапазона: от одноразовой собранной совместными усилиями коллекции несвязанных объектов до мульти-приложения, «разновозрастные» объекты которого разбросаны по сети Internet. Местоположение объектов может быть самым разнообразным: intranet (корпоративная локальнал сеть повышенной надежности с ограниченным доступом, использующал сетевые стандарты и сетевые программно-аппаратные средства, аналогичные Internet), extranet (экстрасеть— объединение корпоративных сетей различных компаний, взаимодействующих друг с другом через Internet) и Internet. Согласно большинству описаний распределенных объектов, они (объекты) могут быть реализованы в различных языках, например С++, Java, Eiffel и Smalltalk. Распределенные объекты могут играть множество ролей. Б одних сигуациях такой объект (или коллекция объектов) используется в качестве сервера, который способен обеспечить услуги, например, по доступу к базе данных, по обработке данных или их передаче. В других ситуациях объекты играют роль клиентов. Распределенные объекты можно использовать в таких объединенных моделях решения проблем, как «классная доска» и мультиагентные системы. Помимо объединенных моделей, распределенные объекты могут быть полезны для реализации таких парадигм параллельного программирования, как SPMD и MPMD. Объектам одного приложения не требуется специального протокола для связи между собой. Коммуникация достигается за счет обычного вызова методов, передачи параметров и использования глобальных переменных. Но, поскольку распределенные объекты расположены в различных адресных пространствах, здесь не обойтись без методов межпроцессного взаимодействия и во многих случалх необходимо сетевое программирование.
Необходи м ость создания распределенных приложений обусловлена разны м и причина м и.
• Необходимые ресурсы (например, базы данных, специализированные процессоры, модемы, принтеры и т.п.) расположены на рааличных компьютерах. Клиентские объекты (объекты, формирующие запрос на обслуживание) взаимодействуют с серверными объектами (объектами, реагирующими на запрос обслуживания) для получения доступа к этим ресурсам.
• Для выполнения некоторой важной работы или решения насущной проблемы необходимо скооперировать объекты, различающиеся временем разработки, разработчиками и местоположением.
• Агенты, реализованные как объекты, отличающиеся узкой специализацией, требуют собственных адресных пространств, поскольку они запускаются как отдельные процессы.
• Объекты используются в качестве базовых модулей, которые реализованы как отдельные программы, каждая из которых имеет собственное адресное пространство.
• Объекты реализованы в SPMD- или МРМП-архитектуре, рассчитанной на использование параллельного программирования, причем эти объекты расположены в различных процессах и на различных компьютерах.
В объектно-ориентированном приложении выполняемая программой работа делится между несколькими объектами. Эти объекты представляют собой модели определенной реальной личности, реального места, предмета или идеи. Выполнение объектно-ориентированной программы вынуждает ее объекты взаимодействовать между собой в соответствии с правилами, заложенными в этой модели. В распределенном объектно-ориентированном приложении некоторые взаимодействующие объекты будут создаваться различными программами, которые, возможно, выполняются на различных компьютерах. В главе 3 упоминалось о том, что каждая выполняемал программа включает один или несколько процессов. Каждый процесс обладает собственными ресурсами. Например, любой процесс имеет собственную память, дескрипторы файлов, стековое пространство, идентификатор и т.п. Задачи, выполняемые в одном процессе, не имеют прямого доступа к ресурсам, принадлежащим другому процессу. Если задачам, выполняемым в одном процессе, необходима информация, хранимая в памяти другого процесса, то эти два процесса должны явно обменяться информацией с помощью файлов, каналов, общей памяти, переменных среды или сокетов. Объекты, которые принадлежат различным процессам и нуждаются во взаимодействии между собой, также должны использовать один из перечисленных выше способов явного обмена информацией. Как правило, С++-разработчик при разработке распределенного объектно-ориентированного приложения сталкивается с необходимостью решения следующих проблем.
• Деко м позиция задачи и ее решения на м ножество объектов, приче м некоторые из них будут принадлежать рааличным процесса м и раз м ещаться на разных компьютерах.
• Обеспечение связи между объектами, принадлежащими различным процесса м (адресным пространствам).
• Синхронизация взаимодействия между локальны м и и удаленны м и объектами.