Автоматическое распараллеливание программ как на уровне объ-
ектного, или байт-кода, при компиляции [1–3], так и на уровне исход-
ного кода (source-to-source) [4] и аппаратном уровне [5] являлось объ-
ектом исследований в течение долгого времени и в настоящее время
остается в центре внимания. Существуют известные продукты, спо-
собные проводить распараллеливание на уровне исходного кода для
различных языков, например Intel Parallel Studio. Однако существую-
щие инструменты предъявляют требования к исходному коду прило-
жения (отсутствие определенных инструкций и др.) Таким образом,
при распараллеливании кода, не написанного специально для распа-
раллеливающей трансляции, возникают проблемы, одной из которых
является обработка исключений.
Многие операции как в составе стандартных библиотек языков,
так и в пользовательском исходном коде, используют механизм ис-
ключений для оповещения вызывающих функций о некорректных си-
туациях, которые могут возникнуть при выполнении указанных опе-
раций. Одни языки (например, Java) имеют строгие спецификации
исключений, при нарушении которых код не может быть скомпилиро-
ван [6]. В таких языках функция или метод, генерирующие (“выбро-
сить”) исключение, должны специфицировать типы выбрасываемых
исключений в декларации. Прочие типы исключений, которые могут
быть выброшены инструкциями, входящими в тело функции или ме-
тода, должны перехватываться в методе или функции. Другие языки
(например, C++) относятся к декларации исключений менее строго
и позволяют не декларировать типы выбрасываемых исключений, а
также указывать типы исключений, которые не выбрасываются функ-
цией или методом [7, 8]. Тем не менее, хотя в некоторых языках нельзя
полностью полагаться на декларацию исключения, при распараллели-
вании исходного кода исключения также обязательно должны быть
учтены. Особенно это утверждение актуально для компонентов про-
грамм, обеспечивающих ввод-вывод, работу с дисками и периферий-
ным оборудованием.
Суть выброса исключения как операции заключается в том, что
в результате генерации исключения стек вызовов раскручивается до
тех пор, пока не будет определен стековый кадр функции, в которой
находится обработчик этого типа исключений. С такой точки зрения
генерацию исключения можно рассматривать как переход вверх по
последовательности вызовов. Нередко обработка исключений реали-
зуется именно с помощью безусловных переходов, например меха-
низмом setjmp/longjmp [8, 9]. В связи с этим при распараллеливании
кода, содержащего обработку или генерацию исключений, возникают
сложности: наличие перехода, ведущего вверх по стеку вызовов (как
правило, за границы распараллеливаемого фрагмента кода), в после-
72 ISSN 0236-3933. Вестник МГТУ им. Н.Э. Баумана. Сер. “Приборостроение”. 2014. № 6
