На данный момент существуют несколько коммерческих инструментов, осуществляющих динамический контроль корректности OpenMP программы. Рассмотрим отладчики Intel Thread Checker[5] и Sun Thread Analyzer[4]. Оба инструмента способны находить ошибки общей памяти и взаимной блокировки в программах, использующих не только OpenMP, но и другие разновидности параллелизма с общей памятью, например, нити POSIX.

Intel Thread Checker имеет два режима работы: зависимый от числа нитей и независимый.

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

Независимый от числа нитей режим работы включается добавлением при компиляции программы с помощью компилятора Intel опции -tcheck. При этом в отлаживаемой программе должны отсутствовать вызовы функций работы с числом нитей, таких как omp_set_num_threads(), omp_get_num_threads(), omp_get_max_threads(), omp_get_thread_num(), и omp_get_num_procs(). В этом режиме программа должна быть запущена на одной нити. В процессе работы параллелизм будет смоделирован и, не смотря на то, что реально при работе программы ошибки не произошли, они будут найдены, как потенциальные. Так же этот режим позволяет получить более подробную информацию об ошибке.

Sun Thread Analyzer требует, чтобы программа была скомпилирована с ключом -xinstrument=datarace. Так же должна быть включена отладочная информация для того, чтобы отладчик мог выдать диагностику с привязкой к исходному коду. Для обнаружения ошибок, запуск программы должен быть произведен на нескольких нитях.

Сравнение приведенных отладчиков было проведено в Center for Computing and Communication RWTH Aachen University в Германии[2]. Intel Thread Checker и Sun Thread Analyzer запускались на нескольких программах с разными параметрами, для определения достоинств и недостатков этих инструментов. Наибольший интерес представляют полученные результаты замеров производительности отлаживаемых программ под управлением данных инструментов и без них, а так же количество потребляемой памяти. Отладчики тестировались на 3 примерах:

- Jacobi. Приближенное решение двумерного уравнения Пуассона методом Якоби.

- SMXV. Умножение матрицы на вектор в случае, когда в матрице имеется большое количество нулевых элементов.

- AIC. Вычисление интеграла адаптивным методом.

В Таблице 1 приведены параметры производительности и потребляемой памяти (в мегабайтах) при работе программы. При этом инструменты тестировались на разных машинах с использованием разных компиляторов:

Intel - запуск программы, скомпилированной компилятором Intel, без отладчика на 2 нитях.

Intel Thread Checker - запуск программы на 2 нитях под управлением этого инструмента в зависимом от числа нитей режиме, т.к. алгоритмы SMXV и AIC используют функции для работы с числом нитей.

Sun - выполнение программы на 2 нитях без режима отладки, с использованием компилятора фирмы Sun.

Sun Thread Analyzer - отладка программы на 2 нитях с помощью Sun Thread Analyzer.

Таблица 1: Характеристики выполнения программ

Из приведенной таблицы видно, что замедление во время отладки программы может достигать сотен раз, в то время как потребление памяти так же увеличивается в десятки раз.

К тому же при проведении данного тестирования было замечено, что Intel Thread Checker работал на 4-х нитях с такой же производительностью, что и на 2-х.

Рассмотренные инструменты отладки, а именно Intel Thread Checker и Sun Thread Analyzer, с успехом могут быть использованы для отладки небольших программ. Однако, из-за значительного увеличения объема потребляемых ресурсов во время отладки они становятся не применимыми для задач, работающих с большими объемами данных и производящими длительные вычисления. Для таких приложений требуется подбирать специальные входные данные, чтобы минимизировать потребляемые ресурсы. В некоторых случаях такой метод может быть не применим, например, когда объем требуемой памяти не сильно зависит от входных данных, или если программа получает на вход данные непосредственно от другого приложения.

В этой главе описана схема работы отладчика, реализующего динамический контроль корректности OpenMP программы.

Изначально имеется исходный код Fortran программы со вставленными директивами OpenMP. Отладчик скомпилирован в объектный файл, и имеет интерфейс в виде набора функций, которые должны быть вызваны в процессе работы отлаживаемой программы, при наступлении соответствующих событий, например, при обращении к памяти. При помощи специальной программы - инструментатора, в исходный код вставляются вызовы интерфейсных функций отладчика. Далее полученный код должен быть скомпилирован вместе с объектным файлом отладчика в выполняемую программу, которую можно запускать на вычислительной системе с общей памятью. В результате работы этой программы будет выдана информация об обнаруженных ошибках. На рисунке 2 представлена описанная схема.

2

Рисунок 2: Общая схема работы отладчика.

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

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

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

В постановке задачи требуется находить два вида ошибок: общей памяти и инициализации, а, следовательно, основным объектом исследований являются переменные и массивы, а точнее обращение к памяти. Но, так как чтение и запись в память связано с переменными и массивами, то можно объединить данные об этих операциях и информацию о переменной в одну структуру, которую назовем VarInfo. И теперь такая структура становится основным объектом, с которым будет работать отладчик.

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

Определим некоторую структуру, которая будет содержать данные о текущем состоянии нити, и назовем ее контекстом (Context). Для каждой нити в каждый момент времени доступен некоторый набор переменных, к которым они могут обращаться, при этом у разных нитей эти наборы обычно разные, т.к. они могут обладать приватными переменными и находиться в разных частях программы. Пусть текущий контекст нити содержит структуры данных, описывающие каждую переменную, (VarInfo) к которой было обращение с момента существования этого контекста. Структура VarInfo может быть взята из текущего контекста нити по некоторому ключу, например, по адресу соответствующей переменной. Конкретные ключи будут приведены далее при описании алгоритмов обнаружения ошибок, так же как будет уточнено содержимое самой структуры Context.

Теперь для полноты описания состояния всей программы следует поместить в вершины приведенного выше дерева, описывающего связи между нитями, структуры описывающие состояния самих нитей, а именно структуры Context. Такое дерево назовем деревом контекстов.

Правила построения дерева контекстов выглядят следующим образом:

· В начале выполнения программы существует только одна нить, а следовательно дерево контекстов должно состоять из одной корневой вершины, соответствующей данной нити.

· При входе в параллельную область создается группа параллельных нитей, которая включает породившую остальные нити (главную нить). В этом случае в дереве контекстов к вершине, соответствующей главной нити до этой параллельной области, добавляются вершины-потомки, соответствующие каждой нити из созданной группы.

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

· При вызове проинструментированной функции, т.е. функции содержащей обращения к отладчику, к вершине данной нити добавляется вершина-потомок, которая становится текущей для этой нити.

· При выходе из функции текущая вершина нити удаляется, и текущей становится ее родительская вершина.

На рисунке 3 показан пример дерева контекстов. В вершинах этого дерева указан уникальный номер нитей, который в отличие от номеров OpenMP у любых двух нитей будет различным.

2

Рисунок 3: Пример дерева контекстов

Построенное дерево будет использоваться при дальнейшем описании алгоритмов, поэтому для удобства описания определим некоторые понятия, которые могут встретиться. Контекст или структура Context соответствует вершине дерева. Текущим контекстом для данной нити называется листовая вершина дерева, которая соответствует этой нити. Для каждой нити существует только один текущий контекст. Родительской вершиной называется вершина, к которой присоединена данная, и расположенная непосредственно над данной вершиной.

Ошибки общей памяти возникают, когда несколько нитей одновременно и независимо работают с одной областью памяти, причем хотя бы одна нить производит запись в эту область. Под независимостью в терминах OpenMP понимается отсутствие каких-либо конструкций синхронизации нитей, позволяющее в каждый момент времени обращаться к памяти только одной из них.

В OpenMP имеются следующие конструкции синхронизации:

· Критические секции.

· Атомарные операторы. Данную конструкцию можно заменить на критическую секцию с уникальным именем.

· Барьерная синхронизация.

· Последовательное выполнение блока в цикле (ordered).

· Механизм замков.

Страницы: 1, 2, 3, 4