Ю. Вахалия - UNIX изнутри (2003) (1114670), страница 74
Текст из файла (страница 74)
Для применения механизма в таких системах необходимо реализовать несколько другую методику подсчета ссылок. 7. 1 О. Другие проблемы, возникающие при синхронизации При разработке и практическом применении сложных механизмов синхронизации для многопроцессорных систем необходимо учитывать несколько важных факторов. Наиболее важные из них будут описаны в этом разделе, 7.1 0.1. Предупреждение возникновения взаимоблокировки Во многих случаях нити необходимо удерживать сразу же несколько ресурсов. Например, в реализации условных переменных, описанных в разделе 7.7, применяется лва объекта простой блокировки, один из которых зашишает данные и логическое условие, в то время как второй используется для зашиты списка нитей, находягцихся в режиме ожидания изменения значения условия. В этом случае попытка получения сразу же нескольких объектов синхронизацин приведет к взаимоблокировке, как это показано на рис.
7.8. Нить Н1 удерживает ресурс Р1 и пытается получить ресурс Р2. В тот же момент времени нить Н2 может являться владельцем Р2 и добиваться доступа к ресурсу Р1. В такой ситуации ни одна из нитей не достигнет своей цели. Обе нити зависнут. Для предупреждения возникновения взаимоблокировки обычно применяется одна из двух методик, называемых иерархической блотптровкой ()т!егагсв!са! !оск!п8) и вероятностпттой блокировкой (згос)тазг!с !ос)г!п8). Иерархический метод основан на назначении определенного порядка зависимых друг от друга т.10.
Другие проблемы, возникающие при синхронизации 317 объектов синхронизапии и требует, чтобы все нити получали такие объекты в указанном порядке. При этом в случае применения, к примеру, условных переменных нить должна занять логическое условие до блокировки связанного списка. Точное соблюдение порядка следования приводит к невозможности возникновения взаимоблоки)ювки. Попытка захвата ~ Н1 Рг Удержание Удержание Попытка захвата чная Р1 Рис. 7.8. Возникновение взаимной блокировки при применении простых объектов синхронизации Иногда возникают ситуации, при которых порядок блокировки требуется изменить. Представьте буферный кэш, который обслуживается при помощи двунаправленного связанного списка дисковых буферов.
Список отсортирован в порядке члаиболее даено использовавшихся» (1еазс гесепг1у цзег1, ЕРтЕГ) элементов. Все буферы, не используемые в текущий момент времени, занесены в этот список. Защита заголовка очереди, а также указателей на предыдущий и последующий элементы поддерживается при помощи единственного объекта блокировки.
Каждый буфер в отдельности использует еще один объект для защиты другой информации, содержащейся внутри буфера. Такой объект необходимо удерживать во время использования буфера. Если нити необходимо загрузить один из дисковых блоков, сначала она запрашивает буфер (используя для этого хэширование или другие указатели), после чего блокирует его.
Затем нить блокирует список ЕИЗ для удаления из него полученного блока. Следовательно, обычный порядок блокировки можно описать фразой: асиачала буфер, затем — список», В некоторых случаях нити нужно получить любой свободный буфер, для чего она обращается к заголовку списка ЕКП. При этом нить сначала блокирует список и только затем блокирует буфер, оказавшийся в списке первым, после чего удаляет его из списка. Этот случай демонстрирует изменение порядка блокировка на противоположный: нить сначала блокирует список и только затем — буфер.
Можно заметить, что в этом случае возможно возникновение взаимоблокировки. Представьте, что одна нить захватывает буфер из заголовка списка и затем пытается заблокировать сам список. В тот же момент времени другая нить, которая уже заблокировала список, пытается занять буфер из его заголовка. Это приведет к тому, что каждая нить приостановит выполнение в ожидании освобождения блокировки, удерживаемой другой нитью.
318 Глава 7. Синхронизация. Многопроцессорные системы Для предупреждения возникновения подобных ситуаций ядро системы использует методику вероятностной блокировки. Если нить пытается получить объект синхронизации в нарушение иерархии, она ис~тользует функпию 1гу (ос(т() вместо (ос(т(). Операция Ьу (ос(т() применяется для получения об». екта, но результатом ее работы в случае обнаружения занятости объекта окажется не блокировка нити, а выход с ошибкой.
В приведенном выше примере нить, которой необходимо получить любой свободный буфер, сначала заблокирует список, а затем будет пытаться получить первый свободный объект при помощи операции сту (ос(с(), перемещаясь по списку. Листинг 7.!б показывает пример применения функции 1ту (ос((() над простыми объектами синхронизации. Листинг 7.10. Пример использования операции тту (осх() )пЪ 1гу 1оск(зр)п1ос~ Ъ *я) ( 11 (тез( апб зеъ(з) !- О) т* объект уже занят *т' гетнгп ЕАТС()КЕ; е1зе ге1цгп 5()ССЕ55: 7.10.2. Рекурсивная блокировка Блокировка называется рекурсивной, если попытка захвата объекта, которым уже обладает нить, окажется успешной и не повлечет приостановку ее вьнюлнения.
В каких случаях можно использовать эту возможность? В каких ситуациях нить пытается запросить объект, которь(м она уже обладает7 Обычно такое происходит, если нить, удерживающая ресурс, вызь(вает процедуру низкого уровня, производящую какие-либо операции с этим ресурсом'. Процедуры могут быть вызваны и другими командами высшего уровня, не занявшими перед этим ресурс. Становится ясно: процедура низкого уровня может попросту не знать о том, что ресурс является заблокированным. Если процедура попытается произвести блокировку, результатом станет зависание процесса.
Описанные выше ситуации можно предупредить, информируя процедуру о блокировке ресурса при помощи дополнительного входного аргумента. Но, к сожалению, такой подход требует изменения интерфейсов взаимодействия, Он может привести к определенным неудобствам, так как процедуры способны производить вызовы дополнительных функций. В результате обновленньпл интерфейс потеряет свойство модульности.
Альтернативным решением проблемы является применение рекурсивной блокировки. При этом возникают определенные перегрузки, так как объекту блокировки необходимо ' Или при рекурсивном вызове самой себя, — Прим, ред, 7.! О. Другие проблемы, возникающие при синхронизации 319 хранить некий идентификатор владельца и проверять его каждый раз при блокировке или запрещении запроса. Однако более важным является тот факт, что рекурсивная блокировка позволяет иметь дело только с общими требованиями, независимо от того, какой конкретный объект блокировки используется нитью. Применение рекурсивной блокировки позволяет строить понятные модульные интерфейсы.
Примером использования методики является осуществление записи каталога файловой системы ВБВ (и/з). Для записи каталогов и отдельных файлов применяется одна и та же процедура па апте(). Доступ к записываемому файлу обычно осуществляется через элемент файловой таблицы, предоставляя>шей указатель на объект упоое этого файла. Таким образом, объект упог)е передается напрямую процедуре ой вптеО, которая и должна в дальнейшем осуществить его блокировку.
Однако дескриптор упог)е при осуществлении записи каталога запрашивается посредством процедуры просмотра имен путей, возвращающей этот объект в уже заблокированном состоянии. Если затем произвести вызов паз аптеО для записи в каталог, результатом станет взаимоблокировка. Для предупреждения возникновения такого состояния необходимо использовать рекурсивную блокировку. 7.10.3. Что лучше. "приостановка выполнения или ожидание в цикле? Сложная синхронизация объектов может быть реализована как блокирующий объект или как сложный ожидающий объект без проведения изменений в свойствах или интерфейсах обоих типов объектов.
Представьте, что ресурс защищен при помощи сложного объекта синхронизации (например, посредством семафора или объекта синхронизации чтения-записи). В реализации большинства механизмов, описываемых в этой главе, если нить пытается получить доступ к объекту и находит его уже занятым, она приостанавливает выполнение в ожидании освобождения этого объекта. Нить может и продолжать выполнение, осуществляя цикл ожидания ресурса.
Выбор между приостановкой выполнения и ожиданием в цикле зависит чаще всего от соображений производительности работы системы. В режиме ждущего цикла занимается процессор, что делает выбор этого варианта нежелательным. Но в системе иногда возникают ситуации, при которых ждущий цикл оказывается удобнее всего. Если нить уже занимает простой объект (шптех) синхронизации, он не имеет права блокировки. Если нить попытается получить еше один простой объект, то она перейдет в режим циклического ожидания. В случае необходимости получения сложного объекта синхронизации занимаемый нитью объект-шпгех будет освобожден (точно по такому же алгоритму происходят действия с условными переменными).
Операции приостановки и возобновления выполнения нити являются громоздкими сами по себе, так как требуют проведения контекстных пере- 320 Глава 7. Синхронизация. Многопроцессорные системы кл|очений и манипуляций с очередями сна и планирования. Одинаково нера. зумным представляется ожидание ресурса, который удерживается в течение продолжительного периода времени, точно так же как и приостановка выполнения нити в ожидании объекта, который вскоре может быть освобожден. Более того, некоторые ресурсы могут удерживаться как на малый, так и на большой промежуток времени, в зависимости от определенных условий.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
