Камерон Хьюз - Параллельное и распределенное программирование на С++

Мы используем диаграммы событий для построения схемы действия обработчика исключительных сигуаций. На рис. 7.6 схематично изображена система, состоящая из семи задач, помеченных буквами А, В, С, D, E, F и H. Обратите внимание на то, что каждая метка (обозначающал задачу) расположена над переключателем. Если переключатели закрыты, компонент функционирует, в противном случае — нет. Крайняя точка слева представляет начало, а крайняя точка справа — конец выполнения. Для успешного завершения программы необходимо найти путь через действующие компоненты. Попробуем продемонстрировать, как применить эгу диаграмму к нашему случаю обработки исключений. Предположим, что мы начинаем программу с выполнения задачи А. Чтобы успешно завершить программу, необходимо корректно решить обе задачи А и С. На языке диаграммы это означает, что переключатели А и С должны быть закрыты. На нашей диаграмме событий переключатели А и С находятся на одной ветви, что свидетельствует об их параллельном выполнении. Если произойдет отказ в любой из этих задач (А или С), будет сгенерировано исключение. Обработчик исключений мог бы снова начать выполнение задач А и С. Однако анализ нашей диаграммы событий показывает, что завершение всей программы будет успешным, если успешным будет выполнение либо ветви АС, либо ветви DE, либо ветви FBH. Поэтому мы проектируем наш обработчик исключений таким образом, чтобы он выполнял один из альтернативных наборов компонентов (например, DE или FBH). Наборы компонентов (AC, DE и FBH) связаны между собой отношением ИЛИ. Это значит, что к успешному завершению программы приведет успешное выполнение любого набора параллельно выполняемых компонентов. Таким образом, простая диаграмма событий (см. рис. 7.6) позволяет понять, как следует построить обработчик исключений. Выражение

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 В and H)

}

} catch(mysterious_condition &E){

start(D and E)

}

};

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

Итак, на рис. 7.7 показано три И-схемы, объединяемые на основе ИЛИ-отношений для получения результата S (который означает успешное завершение работы системы). Диаграмма событий (см. рис. 7.6) и логическая схема (см. рис. 7.7) — это примеры простых методов, которые можно использовать для визуализации критических путей (ветвей) и критических компонентов в некоторой части ПО. После идентификации критических путей и компонентов разработчик должен прелусмотреть ответные действия, которые должна выполнить система в случае, если откажет любой из критических компонентов. Если при этом используется модель завершения, то обработчик исключений не делает попытку возобновить выполнение ПО с точки, в которой возникла исключительная ситуация. Вместо этого осуществляется выход из функции или процедуры, в которой произошло исключение, и предпринимаются действия по пе-револу системы в стабильное (насколько это возможно) состояние. Но если используется модель возобновления, то корректируются условия, создавшие аномалию, и программа возобновляется с точки, в которой возникла исключительнал ситуация. Важно отметить, что при реализации модели возобновления возможны определенные трудности. Например, предположим, что наш код содержит слелующую последовательность вложенных вызовов процедур: