Операционные системы - аспекты параллелизма

Цель лекции: Лекция направлена на изучение вопросов, связанных с оценкой эффективности разрабатываемых методов параллельных вычислений.

3.1. Проблемы параллельного программирования

Традиционное последовательное программирование предполагает пошаговое выполнение команд программы, реализующей некоторый алгоритм. Выполнение программы начинается запуском определенной функции, например main(), с последующим выполнением четко определенной последовательности операций. Если программа поддерживает пользовательский ввод – для каждого события пользовательского ввода определяется своя последовательность обработки. Такие последовательные программы предсказуемы и относительно просты в разработке и отладке.

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

• Передача данных между потоками. Основные способы: передача через разделяемую память, средства потоковой передачи, средства передачи сообщений.
• Синхронизация выполнения потоков: своевременный старт этапов алгоритма, корректный доступ к разделяемым ресурсам и т.д.
• Масштабируемость и распределение нагрузки: многопоточная программа может запускаться на вычислительных системах различных конфигураций, например, с одним центральным процессором (ЦП) или шестнадцатью. Сможет ли программа эффективно использовать имеющиеся 16 процессоров?

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

3.2. Необходимость синхронизации

Предположим, имеется многопоточная программа, работающая с базой данных (БД). Функции, использующие БД построены одинаково и используют однотипные последовательности, включающие следующие три шага:

1. Считать запись из базы данных в локальный буфер потока.
2. Изменить значение записи.
3. Записать модифицированную запись из локального буфера потока в базу данных.

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

Сначала рассмотрим ситуацию, когда вычислительная система имеет один ЦП; предполагается, что операционная система (ОС) использует вытесняющий алгоритм планирования. В этом случае основа проблемы заключается в возможности передачи ЦП от одного потока к другому до завершения им операции с записью БД. На рис. 3.1 представлены три возможных варианта диаграммы выполнения потоков.

Рис. 3.1. Варианты диаграммы выполнения потоков на однопроцессорной системе

Если предположить, что поток А предполагает увеличить значение некоторого поля записи БД на 3, а поток В предполагает увеличить значение той же записи на 5, то мы имеем три возможных конечных значения данного поля записи. Какой именно вариант реализуется при конкретном запуске программы, зависит от взаимных скоростей потоков и моментов передачи ЦП от одного потока к другому. Отметим, что в большинстве случаев поток не может повлиять на данные факторы.

В случае многопроцессорной системы также возможна реализация различных диаграмм выполнения потоков (см. рис. 3.2).

Рис. 3.2. Варианты диаграммы выполнения потоков на многопроцессорной системе

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

Таким образом, результат вычислений в рассмотренном примере не однозначен – все зависит от условий выполнения потоков, и разные запуски программы могут привести к разным результатам! Такая ситуация имеет место при совместном использовании любых ресурсов, в частности, при использовании "обычных" общих (глобальных и статических) переменных. Ситуация, когда два или более потоков используют разделяемый ресурс и конечный результат зависит от соотношения скоростей потоков, называется состязанием или гонками (race conditions).

Критическая секция (КС, critical section) – часть программы, результат выполнения которой может непредсказуемо меняться, если в ходе ее выполнения состояние ресурсов, используемых в этой части программы, изменяется другими потоками.

Критическая секция всегда определяется по отношению к определенным критическим ресурсам (например, критическим данным), при несогласованном доступе к которым могут возникнуть нежелательные эффекты.

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

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

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

Ниже приводится полная постановка задачи организации согласованного доступа к ресурсам.

3.3. Задача взаимного исключения

Постановка задачи взаимного исключения выглядит следующим образом: необходимо согласовать работу n>1 параллельных потоков при использовании некоторого критического ресурса таким образом, чтобы удовлетворить следующим требованиям:

1. одновременно внутри критической секции должно находиться не более одного потока;
2. относительные скорости развития потоков неизвестны и произвольны;
3. критические секции не должны иметь приоритета в отношении друг друга;
4. остановка какого-либо потока вне его критической секции не должна влиять на дальнейшую работу потоков по использованию критического ресурса;
5. любой поток может переходить в любое состояние, отличное от активного, вне пределов своей критической секции;
6. решение о вхождении потоков в их критические секции при одинаковом времени поступления запросов на такое вхождение и равноприоритетности потоков не откладывается на неопределенный срок, а является конечным во времени;
7. освобождение критического ресурса и выход из критической секции должны быть произведены потоком, использующим критический ресурс, за конечное время.

Решением задачи взаимного исключения является программа, которая удовлетворяет всем поставленным условиям при любой реализовавшейся последовательности выполнения потоков (на любой диаграмме выполнения потоков).

Необходимость выполнения условия (1) обсуждалось выше. Условие (2) определяет особенность среды выполнения потоков. Условие (3) говорит о том, что если имеются несколько критических секций, работающих с одним и тем же критическим ресурсом, то при поступлении от нескольких потоков запросов о входе в разные критические секции решение не должно основываться на том, в какую именно КС хочет войти тот или иной поток.

Условия (4) и (5) определяют, что код синхронизации должен быть локализован непосредственно около критической секции и используемые им ресурсы не должны использоваться в других частях программы.

Условия (6) и (7) указывают на типичные ошибки в решениях задачи взаимного исключения – для ряда предложенных решений можно предложить диаграмму выполнения потоков, при реализации которой принятие решения о входе в КС или осуществление выхода из КС могут выполняться в течение бесконечного времени.

Для решения задачи взаимного исключения можно использовать различные имеющиеся в распоряжении аппаратные возможности. Мы рассмотрим следующие возможности: запрещение прерываний, использование разделяемых переменных, использование специальных команд ЦП.