Реклама

Наш канал:

Таненбаум Э.- Архитектура компьютера. стр.360

Рис. 6.23. Ситуация, при которой механизм взаимодействия производителя и потребителя не срабатывает

В этот момент, после того, как потребитель вызвал значения in и out, но еще до того, как он сравнил их, производитель генерирует следующее число. Он помещает это число в буфер в операторе РЗ и инкрементирует in в операторе Р4. Теперь in = 23, a out = 22. В операторе Р5 производитель обнаруживает, что in на единицу больше out, а это означает, что в буфере находится одно число. Исходя из этого, производитель делает неверный вывод о том, что потребитель приостановлен, и вызывает для его запуска метод resume, как показано на рис. 6.23, в. На самом деле потребитель все это время продолжает работать, поэтому вызов метода resume оказывается лишним. Затем производитель начинает формировать следующее число.

В этот момент потребитель продолжает работать. Он успевает вызвать значения in и out из памяти раньше, чем производитель поместил последнее число в буфер. Так как in = 22 и out = 22, потребитель приостанавливается. К этому моменту производитель генерирует следующее число. Он проверяет указатели и обнаруживает, что in = 24, a out = 22. Из этого он делает заключение, что в буфере находится 2 числа (что соответствует действительности), а потребитель функционирует (что неверно). Производитель продолжает цикл. В конце концов, он заполняет буфер и приостанавливается. После этого оба процесса остаются приостановленными до скончания веков.

Сложность здесь в том, что между моментом, когда потребитель вызывает in и out, и моментом, когда он отключается, производитель, обнаружив, что in = = out + 1 и предположив, что потребитель приостановлен (хотя на самом деле он продолжает функционировать), вызывает метод resume, чего делать не нужно, поскольку потребитель и так функционирует. Такая ситуация называется состоянием гонок, поскольку успех метода зависит от того, кто после инкремента out выиграет гонку по проверке in и out.

Проблема гонок хорошо известна. Она настолько серьезна, что через несколько лет после создания Java компания Sun переработала класс Thread, изъяв из него вызовы методов suspend и resume, поскольку они очень часто приводили к состоянию гонок. Предложенное решение заключается в изменении языка, но поскольку наша цель — операционные системы, мы обсудим другое решение, которое используется во многих операционных системах, в том числе UNIX и Windows ХР.

Синхронизация процесса

с использованием семафоров

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

Однако этот метод решает проблему гонок только для двух процессов. В общем случае при наличии п процессов он не работает. Конечно, каждому процессу можно приписать п - 1 таких битов ожидания пробуждения, но это неудобно.