Полное решение задачи о парикмахерской

Несмотря на приложенные усилия (см. листинг «Неполное решение задачи о парикмахерской»), у нас остались опре­деленные сложности.

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

Эта проблема решается добавлением новых семафоров, как показано в лис­тинге. Мы присваиваем каждому пользователю номер (как если бы при входе в парикмахерскую каждый клиент получал номерок). Семафор mutexl обеспечивает защиту доступа к глобальной переменной count, гарантируя уни­кальность номера каждого клиента. Семафор finished превратился в массив из 50 семафоров. Когда клиент садится в кресло, он выполняет инструкцию wait (finished [custnr]), ожидая свой собственный семафор. По окончании стрижки парикмахер выполняет инструкцию signal (finished [b_cust]), от­пуская из кресла того клиента, которого он стриг.

Нам остается рассмотреть, каким образом парикмахер узнает номер клиен­та. Клиент помещает свой номер в очередь enqueue 1 непосредственно перед тем, как сообщить парикмахеру о готовности при помощи семафора cust_ready. Ко­гда парикмахер готов стричь клиента, dequeuel (b_cust) удаляет номер клиен­та из очереди и помещает его в локальную переменную парикмахера b_cust.

semaphore max_capacity = 20;

semaphore sofa = 4;

semaphore barber_chair = 3, coord = 3;

semaphore mutexl = 1, mutex2 = 1;

semaphore cust_ready = 0, leave_b_chair = 0, payment = 0, receipt = 0;

semaphore finished[50] = {0};

void customer()

{

int custnr;

wait(max_capacity);

enter_shop();

wait(mutexl);

count++;

custnr = count;

signal(mutexl);

wait(sofa);

sit_on_sofa();

wait(barber_chair);

get_up_from_sofa();

signal(sofa);

sit_in_barber_chair();

wait(mutex2);

enqueuel(custnr);

signal(cut_ready);

wait(finished[custnr]);

leave_barber_chair();

signal(leave_b_chair);

pay();

signal(payment);

wait (receipt);

exit_shop();

signal(max_capacity);

}

void barber()

{

int b_cust;

while(true);

{

wait(cust_ready);

wait(mutex2);

dequeuel(b_cust);

signal(mutex2);

wait(coord);

cut_hair();

signal(coord);

signal(finished[b_cust]);

wait(leave_b_chair);

signal(barber_chair);

}

}

void cashier()

{

while(true)

{

wait(payment);

wait(coord);

accept_pay();

signal(coord);

signal(receipt);

}

}

void main()

{

parbegin(customer,...[50 раз]..., customer, barber, barber, barber, cashier);

}

Задача об обедающих философах

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

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

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

Обеденный стол философов

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

Листинг. Первое решение задачи об обедающих философах

semaphore fork[5] = {1}; int i;

void philosopher(int i)

{

while(true)

{

think();

wait(fork[i]);

wait(fork[(i+1) mod 5]);

eat ();

signal(fork[(i+1) mod 5]);

signal(fork[i]);

}

}

void main()

{

parbegin(philosopher(0), philosopher(1), philosopher(2), philosopher(3), philosopher(4));

}

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

Листинг. Второе решение задачи об обедающих философах

semaphore fork[5] = {1};

semaphore room = {4};

int i;

void philosopher(int i)

{

while(true)

{

think();

wait(room);

wait (fork[i]);

wait(fork[(i+1) mod 5]);

eat ();

signal(fork[(i+1) mod 5]); signal(forк[i]); signal(room);

}

}

void main()

{

parbegin(philosopher(0), philosopher(1), philosopher(2), philosopher(3), philosopher(4));

}

Задача производителя/потребителя

Сейчас мы рассмотрим одну из общих задач параллельных вычислений — задачу производителя/потребителя. Вот ее обобщенная формулировка. Имеются один или несколько производителей, генерирующих данные некоторого типа (записи, символы и т.п.) и помещающих их в буфер, а также единственный по­требитель, который извлекает помещенные в буфер элементы по одному. Требу­ется защитить систему от перекрытия операций с буфером, т.е. обеспечить, что­бы одновременно получить доступ к буферу мог только один процесс (производитель или потребитель). Мы рассмотрим несколько решений этой зада­чи, с тем чтобы проиллюстрировать как мощь семафоров, так и встречающиеся при их использовании ловушки.

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

/* Производитель */

while(true)

{

/* Производство

элемента v */

b[in] = v;

in++;

}

/* Потребитель */

while(true)

{

while (in < = out)

/* Бездействие */;

w = b[out];

out++;

/* Потребление w*/

}

На рис. показана структура буфера b. Производитель может генериро­вать данные и сохранять их в буфере со своей индивидуальной скоростью. Вся­кий раз при сохранении увеличивается индекс in. Потребитель поступает анало­гично, с тем отличием, что он не должен считывать данные из пустого буфера. Следовательно, перед выполнением считывания он должен убедиться, что произ­водитель обогнал его (in > out).

Рис. Бесконечный буфер задачи произво­дитель/потребитель (Занятая часть буфера заштрихована)

Попытаемся реализовать нашу систему с использованием бинарных семафо­ров. В следующем листинге приведена первая попытка реализации. Вместо работы с ин­дексами in и out мы можем просто отслеживать количество элементов в буфере посредством целой переменной n = in - out. Для осуществления взаимного исключения используется семафор s; семафор delay применяется для ожидания потребителя при пустом буфере.

Листинг. [Неверное] решение задачи производитель/потребитель с использованием бинарных семафоров

int n;

binary_semaphore s=l;

binary_semaphore delay = 0;

void producer()

{

while(true)

{

produce ();

waitB(s);

append();

n++;

if (n == 1) signalB(delay);

signalB(s);

}

}

void consumer()

{

waitB(delay);

while(true) {

waitB (s);

take();

n—;

signalB(s);

consume();

if (n == 0) waitB(delay);

}

}

void main()

{

n = 0;

parbegin(producer, consumer);

}

Решение представляется достаточно простым и очевидным. Производитель может добавлять данные в буфер в любой момент времени. Перед добавлением он выполняет waitB (s), а после добавления— signalB (s), чтобы предотвра­тить обращение к буферу других производителей или потребителя на все время операции добавления данных в буфер. Кроме того, при работе в критическом разделе производитель увеличивает значение n. Если n = 1, то перед этим добав­лением данных в буфер он был пуст, так что производитель выполняет signalB (delay), чтобы сообщить об этом потребителю. Потребитель начинает с ожидания производства первого элемента, используя вызов waitB (delay). За­тем потребитель получает данные из буфера и уменьшает значение n в своем критическом разделе. Если производители опережают потребителя (достаточно распространенная ситуация), то потребитель будет редко блокирован семафором delay, поскольку n обычно положительно. Следовательно, благополучно рабо­тают и производитель, и потребитель.

Тем не менее, в предложенной программе имеется один изъян. Когда потре­битель исчерпывает буфер, он должен сбросить семафор delay с помощью инст­рукции if (n == 0) waitB (delay);, чтобы дождаться размещения данных в буфере производителем. Рассмотрим сценарий, приведенный в табл. «Возможный сценарий работы программы». В стро­ке 14 потребитель не выполняет операцию waitB. Он действительно исчерпал буфер и установил n равным 0 в строке 8, но до проверки значения n в строке 14 оно было изменено производителем. В результате signalB не соответствует предшествующему waitB. Значение n, равное -1 в строке 20, означает, что по­требитель пытается извлечь из буфера несуществующий элемент. Простое пере­мещение проверки в критический раздел потребителя недопустимо, так как мо­жет привести к взаимоблокировке (например, после строки 8).

Таблица «Возможный сценарий работы программы»

Решение проблемы заключается во введении вспомогательной переменной, значение которой присваивается в критическом разделе и используется вне его, как показано в листинге «Верное решение задачи…». Внимательно рассмотрев приведенный код, вы убе­дитесь в отсутствии возможных взаимоблокировок.

Листинг. Верное решение задачи производитель/потребитель с использованием бинарных семафоров

int n;

binary_semaphore s = 1;

binary_semaphore delay = 0;

void producer()

{

while(true)

{

produce();

waitB(s);

append();

n++;

if (n == 1) signalB(delay);

signalB (s);

}

}

void consumer()

{

int m; /* Локальная переменная */

waitB(delay);

while(true)

{

waitB(s);

take();

n—;

m = n;

signalB(s);

consume();

if (m == 0) waitB(delay);

}

}

void main()

{

n = 0;

parbegin(producer, consumer);

}

Несколько более простое решение можно получить при использовании обобщенных семафоров (именуемых также се­мафорами со счетчиками). Переменная n в этом случае является семафором; ее значение остается равным количеству элементов в буфере. Предположим теперь, что при переписывании этой программы произошла ошибка, и опе­рации signal (s) и signal (n) оказались взаимозамененными. Это может привести к тому, что операция signal (n) будет выполняться в критическом разделе производителя без прерывания потребителя или другого производи­теля. Повлияет ли это на выполнение программы? Нет, поскольку потреби­тель в любом случае должен ожидать установки обоих семафоров перед про­должением работы.

Листинг. Решение задачи производитель/потребитель с использованием семафоров

semaphore n = 0;

semaphore s = 1;

void producer ()

{

while(true)

{

produce();

wait(s);

append();

signal(s);

signal(n);

}

}

void consumer()

{

while(true)

{

wait(n);

wait(s);

take();

signal(s);

consume();

}

}

void main()

{

parbegin(producer, consumer);
}

Теперь предположим, что взаимозаменены операции wait(n) и wait(s). Это приведет к фатальным последствиям. Если пользователь войдет в критиче­ский раздел, когда буфер пуст (n.count = 0), то ни один производитель не сможет добавить данные в буфер и система окажется в состоянии взаимной бло­кировки. Это хороший пример тонкости работы с семафорами и сложности кор­ректной разработки параллельно работающих процессов.

Стратегии краткосрочного планирования