Осуществление записи каталога файловой системы BSD
Описанные ситуации можно предупредить, информируя процедуру о блокировке ресурса при помощи дополнительного входного аргумента. Но, к сожалению, такой подход требует изменения интерфейсов взаимодействия.
Он может привести к определенным неудобствам, так как процедуры способны производить вызовы дополнительных функций. В результате обновленный интерфейс потеряет свойство модульности. Альтернативным решением проблемы является применение рекурсивной блокировки.
При этом возникают определенные перегрузки, так как объекту блокировки необходимо хранить некий идентификатор владельца и проверять его каждый раз при блокировке или запрещении запроса. Однако более важным является тот факт, что рекурсивная блокировка позволяет иметь дело только с общими требованиями, независимо от того, какой конкретный объект блокировки используется нитью. Применение рекурсивной блокировки позволяет строить понятные модульные интерфейсы.
Примером использования методики является осуществление записи каталога файловой системы BSD (ufs). Для записи каталогов и отдельных файлов применяется одна и та же процедура ufs_write(). Доступ к записываемому файлу обычно осуществляется через элемент файловой таблицы, предоставляющей указатель на объект vnode этого файла. Таким образом, объект vnode передается напрямую процедуре ufs_write(), которая и должна в дальнейшем осуществить его блокировку. Однако дескриптор vnode при осуществлении записи каталога запрашивается посредством процедуры просмотра имен путей, возвращающей этот объект в уже заблокированном состоянии. Если затем произвести вызов ufs_write() для записи в каталог, результатом станет взаимоблокировка. Для предупреждения возникновения такого состояния необходимо использовать рекурсивную блокировку.
Что лучше: приостановка выполнения или ожидание в цикле?
Сложная синхронизация объектов может быть реализована как блокирующий объект или как сложный ожидающий объект без проведения изменений в свойствах или интерфейсах обоих типов объектов. Представьте, что ресурс защищен при помощи сложного объекта синхронизации (например, посредством семафора или объекта синхронизации чтения-записи). В реализации большинства механизмов, описываемых в этой главе, если нить пытается получить доступ к объекту и находит его уже занятым, она приостанавливает выполнение в ожидании освобождения этого объекта. Нить может и продолжать выполнение, осуществляя цикл ожидания ресурса.
Выбор между приостановкой выполнения и ожиданием в цикле зависит чаще всего от соображений производительности работы системы. В режиме ждущего цикла занимается процессор, что делает выбор этого варианта нежелательным. Но в системе иногда возникают ситуации, при которых ждущий цикл оказывается удобнее всего. Если нить уже занимает простой объект (mutex) синхронизации, он не имеет права блокировки. Если нить попытается получить еще один простой объект, то она перейдет в режим циклического ожидания. В случае необходимости получения сложного объекта синхронизации занимаемый нитью объект-mutex будет освобожден (точно по такому же алгоритму происходят действия с условными переменными).
Операции приостановки и возобновления выполнения нити являются громоздкими сами по себе, так как требуют проведения контекстных переключений и манипуляций с очередями сна и планирования. Одинаково неразумным представляется ожидание ресурса, который удерживается в течение продолжительного периода времени, точно так же как и приостановка выполнения нити в ожидании объекта, который вскоре может быть освобожден.
Более того, некоторые ресурсы могут удерживаться как на малый, так и на большой промежуток времени, в зависимости от определенных условий. Например, ядро может хранить в памяти некий список свободных дисковых блоков. Если список становится пустым, его необходимо заполнить новыми данными о свободных блоках. В большинстве случаев список блокируется на небольшие интервалы времени, в течение которых происходит добавление или удаление его элементов. Если при этом необходимо производить операции ввода-вывода, список окажется заблокированным на большой период времени.
Следовательно, ни ждущий цикл, ни блокировка не окажется в данном случае идеальным выходом. Одним из вариантов решения проблемы является использование двух объектов синхронизации. При этом блокирующий объект применяется только в случае необходимости пополнения списка. Однако наиболее предпочтительным вариантом в этом случае является использование другого, более гибкого элемента синхронизации.
Опубликовал katy
July 06 2015 18:02:15 ·
0 Комментариев ·
1736 Прочтений ·
• Не нашли ответ на свой вопрос? Тогда задайте вопрос в комментариях или на форуме! •
Комментарии
Нет комментариев.
Добавить комментарий
Рейтинги
Рейтинг доступен только для пользователей.
Пожалуйста, залогиньтесь или зарегистрируйтесь для голосования.
Нет данных для оценки.
Гость
Вы не зарегистрированны? Нажмите здесь для регистрации.
Главная
Каталог файлов
