4.2 Примеры использования обработчиков завершения

Поскольку при использовании SEH компилятор и операционная система вместе контролируют выполнение Вашего кода, то лучший, на мой взгляд, способ продемонстрировать работу SEH — изучать исходные тексты программ и рассматривать порядок выполнения операторов в каждом из примеров.

Поэтому в следующих разделах приведен ряд фрагментов исходного кода, а связанный с каждым из фрагментов текст поясняет, как компилятор и операционная система изменяют порядок выполнения кода.

Fuction1

Чтобы оценить последствия применения обработчиков завершения, рассмотрим более конкретный пример:

DWORD Function1() { DWORD dwTemp; // 1 Что-то делаем здесь

__try { // 2. Запрашиваем разрешение на доступ // к защищенным данным, а затем используем их WaitForSingleObject(g_hSem, INFINITE); g_dwProtectedData = 5; dwTemp = g_dwProtectedData; }

_finally { // 3 Даем и другим попользоваться защищенными данными ReleaseSemaphore(g_hSem, 1, NULL); }

// 4 Продолжаем что-то делать return(dwTemp); }

Пронумерованные комментарии подсказывают, в каком порядке будет выполняться этот код. Использование в Funcion1 блоков try-finally на самом деле мало что дает. Код ждет освобождения семафора, изменяет содержимое защищенных данных, сохраняет новое значение в локальной переменной divTemp, освобождает семафор и возвращает повое значение тому, кто вызвал эту функцию.

Funcion2

Теперь чуть-чуть изменим код функции и посмотрим, что получится:

DWORD Funcion2()

{

DWORD dwTemp;

// Что-то делаем здесь ...

__try

{

// 2 Запрашиваем разрешение на доступ

// к защищенным данным, а затем используем их

WaitForSingleObject(g_nSem, INFINITE);

g_dwProtectedData = 5;

dwTemp = g_dwProlecledData;

// возвращаем новое значение

return(dwTemp);

}

_finally

{

// 3 Даем и другим попользоваться защищенными данными

ReleaseSemaphore(g_hSem, 1, NULL);

}

// продолжаем что-то делать - в данной версии

// этот участок кода никогда не выполняется

dwTemp = 9; return(dwTemp);

}

В конец блока try в функции Funcion2 добавлен оператор return. Он сообщает компилятору, что Вы хотите выйти из функции и вернуть значение переменной dwTemp (в данный момент равное 5). Но, если будет выполнен return, текущий поток никогда не освободит семафор, и другие потоки не получат шанса занять этот сема фор. Такой порядок выполнения грозит вылиться в действительно серьезную проблему ведь потоки, ожидающие семафора, могут оказаться не в состоянии возобновить свое выполнение.

Применив обработчик завершения, мы не допустили преждевременного выполнения оператора return. Когда return пытается реализовать выход из блока try, компилятор проверяет, чтобы сначала был выполнен код в блоке finally, — причем до того, как оператору return в блоке try будет позволено реализовать выход из функции. Вызов ReleaseSemaphore в обработчике гарантирует освобождение семафора — поток не сможет случайно сохранить права на семафор и тем самым лишить процессорного времени все ожидающие этот семафор потоки.

После выполнения блока finаllу функция фактически завершает работу. Любой код за блоком finally не выполняется, поскольку возврат из функции происходит внутри блока try. Так что функция возвращает 5 и никогда — 9.

Каким же образом компилятор гарантирует выполнение блок finally до выхода из блока try? Дело вот в чем. Просматривая исходный текст, компилятор видит, что Вы вставили return внутрь блока try. Тогда он генерирует код, который сохраняет воз вращаемое значение (в нашем примере 5) в созданной им же временной перемен ной. Затем создаст код для выполнения инструкций, содержащихся внутри блока finally, — это называется локальной раскруткой (local unwind) Точнее, локальная рас крутка происходит, когда система выполняет блок finаllу из-за преждевременною выхода из блока try Значение временной переменной, сгенерированной компилятором, возвращается из функции после выполнения инструкций в блоке finаllу.

Как видите, чтобы все это вытянуть, компилятору приходится генерировать дополнительный код, а системе — выполнять дополнительную работу. На разных типах процессоров поддержка обработчиков завершения реализуется по-разному. Например, процессоруА1рhа понадобится несколько сотен или даже тысяч машинных команд, чтобы перехватить преждевременный возврат из try и вызвать код блока finаllу Поэтому лучше не писать код, вызывающий преждевременный выход из блока try обработчика завершения, — это может отрицательно сказаться на быстродействии программы. Чуть позже мы обсудим ключевое слово _leave, которое помогает избе жать написания кода, приводящего к локальной раскрутке.

Обработка исключений предназначена для перехвата тех исключений, которые происходят не слишком часто (в нашем случае — преждевременного возврата). Если же какое-то исключение — чуть ли не норма, гораздо эффективнее проверять его явно, не полагаясь на SEH.

Заметьте: когда поток управления выходит из блока try естественным образом (как в Funсешщт1), издержки от вызова блока finally минимальны При использовании компилятора Microsoft на процессорах x86 для входа finаllу при нормальном выходе из try исполняется всего одна машинная команда — вряд ли Вы заметите ее влияние на быстродействие своей программы Но издержки резко возрастут, если компилятору придется генерировать дополнительный код, а операционной системе — выполнять дополнительную работу, как в Function2.

Function3

Снова изменим код функции:

DWORD Function3()

{

DWORD dwTemp;

// 1 Что-то делаем здесь

__try

{

// 2. Запрашиваем разрешение на доступ

// к защищенным данным, а затем используем их

WaitForSingleObject(g_

hSem, INFINITE);

g_dwProtectedData = 5;

dwTemp = g_dwProtectedData;

// пытаемся перескочить через блок finally

goto ReturnValue:

}

__finally

{

// 3. Даем и другим попользоваться защищенными данными

ReleaseSemaphore(g_hSem, 1, NULL);

}

dwTemp = 9;

// 4. Продолжаем что-то делать

ReturnValue:

return(dwTemp);

}

Обнаружив в блоке try функции Function3 оператор gofo, компилятор генерирует код для локальной раскрутки, чтобы сначала выполнялся блок finаllу. Но на этот раз после finаllу исполняется код, расположенный за меткой RetumValue, так как воз врат из функции не происходит ни в блоке try, ни в блоке finally. B итоге функция возвращает 5. И опять, поскольку бы прервали естественный ход потока управления из try в finally, быстродействие программы — в зависимости от типа процессора — может снизиться весьма значительно.