Густав Олссон, Джангуидо Пиани - Цифровые системы автоматизации и управления (1087169), страница 105
Текст из файла (страница 105)
лает из двух модулей фактически последовательный процесс. Тот же результат можне получить, исключив Й и выполняя оба процесса последовательно в одном цикле. Другое решение — переустанавливать защитную переменную Й после проверки ес значения и перед доступом к защищенному ресурсу т. е. все процессы должны иметь следующий вид гереаСцпС!! !1 = Спяе; 11:= Га!зе; (* защищенный ресурс *) 11:= Сгце; В этом случае процессы не связаны, и условие живучести выполнено, но решение не является корректным.
Если прерывание для переключения процесса останавлнцц ет процесс Л после контроля Й = сгпе, но перед присваиванием Й = 1а!зе, а процесс В производит аналогичную проверку Й, то оба процесса получают доступ к зашише" ному ресурсу, что противоречит требованию безопасности. Использование для за щиты ресурса только одной переменной приводит к необходимости зашилцать иере менную, поскольку она сама становится общим ресурсом.
Было предложено несколько решений, основанных на нескольких переменил'х заШиты, но они скорее могут считаться курьезами, имеющими мало практическо ского значения. В закллочение отметим, что для синхронизации параллельных процес ~ ессоя я исаыц лУчше не вводить новых переменных, поскольку они добавляют новые связи и са становятся об шими ресурсами. Для того чтобы обойти эту проблему, некоторые процессоры имеют ком ом аиду Сезг апя! вес (" проверить и установить"), выполняюшую проверкузначения У' ияб девать вой переменной и ее переустановку в ходе одной операции, которую нельзя преРв Смысл команды сезс апя! зес в том, что на ее базе можно построить процедур ы сиц е емец хроннзации и защиты Ресурсов.
Объединения в одцои операции проверки пер ной и ее модификации достаточно для обеспечения защиты. Команда Сезг апя! зеС функционально эквивалентна циклу геас1-шояс!Гу-лулч 'Се нз шине Ъ'МЕЬця (раздел 8.3.2). В обоих случаях гарантируется неразрывность д . цу» операций — чтения н записи. Если команда СезС апг! яеС отсутствует в использу емок! языке программирования или в наборе команд процессора, то ее можно смоделнР о- другими средствами при условии, что допустим запрет прерываний на короткое ,цть крени Р~ализация критических секций и взаимного исключения в распределенной систе.зма по себе представляет проблему.
Для начала, нет прямого эквивалента команды чцсям С апс! зес, поскольку в этом случае имеется более одного процессора. В принципе, Лцяс а яякц ' каждого ресурса можно установить единого координатора. Любой процесс, жела- ив получить доступ к ресурсу, сначала запрашивает координатора, который дает цяцллй Решение только одному из запрашивающих процессов. Однако это решение не явцзре гся столь простым, как кажется. Единый координатор процессов является узким ляется кесто ь ом — и при его отказе ресурс остается либо заблокированным, лиоо незащищенцыы.
и Более того, если ресурс является просто переменной в памяти, то строить целый цоритм для его защиты нерационально. На самом деле координатор сам является (хс ,сурсам, за доступ к которому будет происходить конкуренция, не говоря Уже о том, ягп ц Распределенной системе для посылки запроса нужно еще получить и доступ к каццяу связи. Возможной альтернативой, как уже было показано для коммуникациопых сетей 1раядел 9.5), является использование маркера, который перемешается между процессами.
При этом в критическую секцию может войти только владелец маркера. 3десь возникают те же проблемы, что и в сетях; в случае сбоя в процессе, являющемгя владельцем маркера, должен существовать механизм регенерации маркера. По»тому для защиты небольшого числа переменных в памяти этот метод может оказатьгя громоздким и трудно реализуемым. В заключение отметим, что в распределенных системах не существует практичнопх эффективного и простого метода защиты ресурсов, сравнимого с командой лекс апс! зеС в однопроцессорных конфигурациях. Каждый случай необходимо оцецццать индивидуально и выбирать соответствующее практическое решение.
1В 3 3. Тупики Рассмотрим ситуацию, в которой два или больше процессов в системе приостацпцпены и ожидают каких-нибудь событий. Если такие события для каждого из ожидцюших процесса могут быть инипиированы только другим ожидающим процессом, гц ц "се процессов окажутся в состоянии бесконечного ожидания. Такая ситуация на'иццется тупиком (ЫеалПосй) (рис.
13.7). пл "В" епл "В" Нс. С0.7. Тупик, а — взянмный; 6 циркулярный ~ лава ~ и. ~ ~рограммирование систем реального вре ремень Похожая ситуация возникает, когда один или несколько процессов продолжа ' аютис полняться фактически на одном месте. Это называется зависанием (згаи цг,ол) В ' пример, если процесс непрерывно проверяет значение условной переменной, ко д которве не изменяется, поскольку все остальные процессы также заняты проверкой Й, внии словами, процессы, оказавшиеся в тупике, находятся в очереди ожидания Гт е . е.
онв блокированы), а зависшие процессы исполняются, но фактически на одном мест Тупик и одноврсменнвяй доступ к защищенному ресурсу яв.ляются двумя сими иммет. ричными проблемами, относящимися к чрезвычайным ситуациям. В одном сл,, случае каждый процесс ждет других процессов, во втором — несколько процессов выло, познаются параллельно. Можно предложить несколько подходов к решению проблемы тупиков. Прост стейшим из них является полное игнорирование проблемы и работа в режиме, когда и „ возникновении тупика некоторые процессы уничтожаются, например операторои или производится ручная перезагрузка системы.
Естественно, такое решение неприемлемо для систем реального времени, в особенности, если они должны работать бвв участия оператора. Кроме стратегии с привлечением оператора, существуют еще и другие — автоматического обнаружения и предотвращения. Первая предполагает перераспределение ресурсов для разрешения ситуации или, в крайнем случае, уничтожение одного вз процессов. Вторая — распределение ресурсов так, что тупики не возникают вообще. Для обнаружения тупиковой ситуации необходимо непрерывно проверять состояние всех исполнягощихся процессов и их взаимодействие для обнаружения циклов типа показанных на рис. 10.7. Такой контроль можно делать с помощью фоновой (Ьасййгоипгв) программы, периодически запускаемой планировщиком. Однако и такзя программа не может гарантированно выявить все тупиковые ситуации, В распределен.
ных системах информация о состоянии всех процессов на всех ЭВМ также должна поступать к программе обнаружения тупиковых ситуаций. Помимо повьпиенной нагруз ки на сеть, которая при этом возникает, имеется риск несогласованности сообщений о состоянии процессов, в результате которого может произойти ошибочное выявление тупиковой ситуации с последующим уничтожением соответствующих процессов. Предотвращение означает попытку вообще избежать ситуаций, которые могу~ привести к тупику.
Программы должны быть структурированы и взаимодействие процессов должно быть организовано таким образом, чтобы тупиковые ситуации были исключены вообще. Для возникновения тупика должны выполниться одновременно несколько ус словий. Если хотя бы одно из них не выполнено, тупик не может возникнуть. 1. Взаимное исключение. Существуют системные ресурсы, к которым разр з ешев монопольный доступ. 2. Невьп есняюшее распределение ресурсов.
Ресурс может быть освобожден ен толь е может ко тем процессом, который его захватил, или, иначе говоря, ресурс не и быть освобожден извне захватившего его процесса. 3. Последовательный захват ресурсов. Процесс запрашивает ресурсы по од ному т. е. по мере необходимости. 4. Захват ресурсов в обратном порядке.
Эти четыре утвержления косвенно дают ключ к предотвращению тупиковых х си туаций. Достаточно, чтобы одно из них не выполнялось, и тупик не возникнет. 1й д, г,инхронизвции ~процессов — сема<ромы и ооом ~ ив Первое утверждение выполняется всегда, так как взаимное исключение является ври внципиальным для гарантии упорядоченного управления общими ресурсами.
Второе утверждение требует, чтобы операционная система распознавала тупиковые , ситуации и реагировала соответственно, вынуждая процесс освободить ресурс З о решение приемлемо лишь в случае, если допускается принудительное уничтоже„ие процесса, и зависит от механизма восстановления. В соответствии с третьим утверждением альтернативой выделению по одному является выделение всех необходимых ресурсов одновременно. Практичность этого щения, естественно, зависит от вида этих ресурсов и от того, могут ли без них обой„сь другие процессы, пока не завершится захвативший их процесс.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
