Глава 5. алгоритмы синхронизации

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

Interleaving, race condition и взаимоисключения

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

    1. Отрезать ломтик хлеба.
    2. Отрезать ломтик колбасы.
    3. Намазать ломтик хлеба маслом.
    4. Положить ломтик колбасы на подготовленный ломтик хлеба.

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

Пусть имеется две активности

P: a b c
Q: d e f,

где a, b, c, d, e, fатомарные операции. При последовательном выполнении активностей мы получаем следующую последовательность атомарных действий:

PQ: a b c d e f

Что произойдет при исполнении этих активностей псевдопараллельно, в режиме разделения времени? Активности могут расслоиться на неделимые операции с различным их чередованием, то есть может произойти то, что на английском языке принято называть словом interleaving. Возможные варианты чередования:

а b c d e f
a b d c e f
a b d e c f
a b d e f c
a d b c e f
......
d e f a b c

То есть атомарные операции активностей могут чередоваться всевозможными способами с сохранением своего порядка расположения внутри активностей. Так как псевдопараллельное выполнение двух активностей приводит к чередованию их неделимых операций, то результат псевдопараллельного выполнения может отличаться от результата последовательного выполнения. Рассмотрим пример. Пусть у нас есть две активности P и Q, состоящие из двух атомарных операций каждая:

P: x=2 Q: x=3
  y=x-1   y=x+1

Что мы получим в результате их псевдопараллельного выполнения, если переменные x и y являются общими для активностей? Легко видеть, что возможны четыре разных набора значений для пары (x, y): (3, 4), (2, 1), (2, 3) и (3, 2). Мы будем говорить, что набор активностей (например, программ) детерминирован, если всякий раз при псевдопараллельном исполнении для одного и того же набора входных данных он дает одинаковые выходные данные. В противном случае он недетерминирован. Выше приведен пример недетерминированного набора программ. Понятно, что детерминированный набор активностей можно безбоязненно выполнять в режиме разделения времени. Для недетерминированного набора такое исполнение нежелательно.

Про недетерминированный набор программ (и активностей вообще) говорят, что он имеет race condition (состояние гонки, состояние состязания). В приведенном выше примере процессы состязаются за вычисление значений переменныхx и y.

Задачу упорядоченного доступа к разделяемым данным (устранение race condition), в том случае, если нам не важна его очередность, можно решить, если обеспечить каждому процессу эксклюзивное право доступа к этим данным. Каждый процесс, обращающийся к разделяемым ресурсам, исключает для всех других процессов возможность одновременного с ним общения с этими ресурсами, если это может привести к недетерминированному поведению набора процессов. Такой прием называется взаимоисключением (mutual exclusion). Если очередность доступа к разделяемым ресурсам важна для получения правильных результатов, то одними взаимоисключеньями уже не обойтись.

Критическая секция

Важным понятием при изучении способов синхронизации процессов является понятие критической секции (critical section) программы. Критическая секция - это часть программы, исполнение которой может привести к возникновению race condition. Чтобы исключить эффект гонок по отношению к некоторому ресурсу, необходимо организовать работу так, чтобы в каждый момент времени только один процесс мог находиться в своей критической секции, связанной с этим ресурсом. Иными словами, необходимо обеспечить реализацию взаимоисключения для критических секций программ. Реализация взаимоисключения для критических секций программ с практической точки зрения означает, что по отношению к другим процессам, участвующим во взаимодействии, критическая секция начинает выполняться как атомарная операция. Давайте рассмотрим следующий пример, в котором псевдопараллельные взаимодействующие процессы представлены действиями различных студентов:

Время Студент 1 Студент 2 Студент 3
17-05 Приходит в комнату    
17-07 Обнаруживает, что хлеба нет    
17-09 Уходит в магазин    
17-11   Приходит в комнату  
17-13   Обнаруживает, что хлеба нет  
17-15   Уходит в магазин  
17-17     Приходит в комнату
17-19     Обнаруживает, что хлеба нет
17-21     Уходит в магазин
17-23 Приходит в магазин    
17-25 Покупает 2 батона на всех    
17-27 Уходит из магазина    
17-29   Приходит в магазин  
17-31   Покупает 2 батона на всех  
17-33   Уходит из магазина  
17-35     Приходит в магазин
17-37     Покупает 2 батона на всех
17-39     Уходит из магазина
17-41 Возвращается в комнату    
17-43      
17-45      
17-47   Возвращается в комнату  
17-49      
17-51      
17-53     Возвращается в комнату

Здесь критический участок для каждого процесса — от операции “Обнаруживает, что хлеба нет” до операции “Возвращается в комнату” включительно. В результате отсутствия взаимоисключения мы из ситуации “Нет хлеба” попадаем в ситуацию “Слишком много хлеба”. Если бы этот критический участок выполнялся как атомарная операция — “Достает 2 батона хлеба”, то проблема образования излишков была бы снята.

Время Студент 1 Студент 2 Студент 3
17-05 Приходит в комнату    
17-07 Достает два батона хлеба    
17-43   Приходит в комнату  
17-47     Приходит в комнату

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

Итак, для решения задачи необходимо, чтобы в том случае, когда процесс находится в своем критическом участке, другие процессы не могли войти в свои критические участки. Мы видим, что критический участок должен сопровождаться прологом (entry section) – “закрыть дверь изнутри на засов” - и эпилогом (exit section) – “отодвинуть засов”, которые не имеют отношения к активности одиночного процесса. Во время выполнения пролога процесс должен, в частности, получить разрешение на вход в критический участок, а во время выполнения эпилога - сообщить другим процессам, что он покинул критическую секцию.

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

while (some condition) {

entry section

critical section

exit section

remainder section

}

Здесь под remainder section понимаются все атомарные операции, не входящие в критическую секцию.

Оставшаяся часть этой главы посвящена различным способам программной организации пролога и эпилога критического участка.

Наши рекомендации