Мониторы.

Рассмотренный алгоритм Деккера имеет некоторые недостатки. Чтобы от них избавиться создали мониторы.

Хоар 1974 год. Монитор – это механизм организации параллелизма, который содержит как данные, так и процедуры, необходимые для динамического распределения общего ресурса или группы общих ресурсов. Чтобы обеспечить выделение нужного ресурса, процесс должен обратиться к конкретной процедуре монитора. Монитор находится под жестким контролем, здесь осуществляется взаимное исключение, так что в каждый момент времени только одному процессу разрешается войти в монитор. Процессы, которые хотят войти в монитор, переходят в режим ожидания, причем время и режим ожидания определяет сам монитор. Внутренние данные могут быть либо глобальные, либо локальные, но ко всем этим данным можно обращаться только изнутри монитора. Если процесс обращается к монитору за ресурсом, и обнаруживается, что этот ресурс уже занят, то монитор выдает команду WAIT (имя условия). Переменные-условия совсем не похожи на обычные переменные. Если определяется такая переменная, то заводится очередь, в которую включаются ожидающие процессы, причем для каждой отдельно взятой причины назначается собственное имя переменной-условия. Со временем процесс, который занимал данный ресурс, для возврата ресурса обращается к монитору. Если уже имеются процессы, ожидающие ресурса, то монитор применяет примитив SIGNAL (имя условия). В противном случае монитор вносит ресурс в список свободных. Примером монитора является кольцевой буфер – структура данных, широко применяемая в ОС для буферизации обменов между процессом-производителем и процессом-потребителем. Производитель, обнаруживший, что буфер заполнен, вызывает команду ожидания wait (буфер не заполнен). Потребитель, обнаруживший, что буфер пуст, вызывает wait (буфер не пуст). Производитель, помещающий данные в буфер, выдает signal (буфер не пуст). Потребитель, извлекающий данные, выдает signal (буфер не заполнен).

10. Тупики.

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

• Взаимное исключение – означает, что процессы заявляют исключительные права на управление своими ресурсами.

• Ожидание дополнительных ресурсов – это означает, что процессы могут удерживать за собой ресурсы, ожидая выделения им дополнительных запрошенных ресурсов.

• Неперераспределяемость – означает, что ресурсы нельзя принудительно отнимать у процесса.

• Круговое ожидание – означает, что существует цепочка процессов, в которой каждый процесс удерживает ресурс, запрашиваемый другим процессом, который в свою очередь удерживает другой ресурс и т.д.

Основные направления научных исследований в области тупиков – это предотвращение тупиков, обход тупиков, обнаружение тупиков, восстановление после тупиков.

Предотвращение тупиков.

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

Обход тупиков.

Реализация основывается на алгоритме банкира, предложенный Дейкстрой, который как бы имитирует действия банкира (на месте ОС), выдает ссуды клиентам (выделяет ресурсы) и принимает платежи (возвращает ресурсы). Банкир, выдавая ссуды, оценивает свой капитал. Если капитал приближается к минимуму, то банкир откладывает выдачу ссуды и ждет возврата ссуды от других клиентов. А чтобы понять, является ли его состояние безопасным, банкир проверяет, может ли он предоставить достаточно ресурсов для завершения работы какого-либо клиента и возврата ссуды.

Согласно этому алгоритму считается, что состояние системы надежно, если имеется возможность завершить выполнение всех пользовательских программ и возвратить ресурсы системе, и состояние ненадежно в противном случае.

Обнаружение тупиков.

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

Восстановление после тупиков.

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

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

28 марта 2012 г.