3. Закрытие одного из файловых дескрипторов.

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

После

родительский процесс сохраняет свои файловые блокировки, но дочерний процесс — нет. Если бы дочерние процессы наследовали блокировки, два процесса пришли бы, в конечном счете, к блокировке записи на одной области файла.

Однако файловые блокировки наследуются в

. Поскольку в POSIX не определено, что происходит с блокировками после , все варианты Unix сохраняют их [92] .

И Linux, и System V поддерживают как обычные, так и обязательные блокировки. Обязательные блокировки устанавливаются и реализуются с помощью того же механизма

, который используется для рекомендательной блокировки записей. Блокировки считаются обязательными, если бит setgid заблокированного файла установлен, но его бит группового выполнения — нет. В противном случае применяется рекомендательное блокирование.

При активизации обязательного блокирования системные вызовы

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

Обязательное блокирование записи приводит к большей потере производительности, чем рекомендательное блокирование, поскольку каждый вызов

и должен быть проверен на предмет конфликтов с блокировками. Оно также не настолько переносимо, как рекомендательное блокирование POSIX, поэтому в большинстве приложений обязательное блокирование применять не следует.

И рекомендательное, и обязательное блокирование предназначены для предотвращения доступа процесса к файлу или его части, которая используется другим процессом. Когда блокировка установлена, процесс, которому необходим доступ к файлу, должен подождать завершения процесса, владеющего блокировкой. Эта структура подходит для большинства применений, но иногда программа использует файл до тех пор, пока он не понадобится другой программе, и желает получить при необходимости эксклюзивный доступ к файлу. Для этого Linux предлагает механизм аренды файлов (в других системах это называется периодическими блокировками (oplocks)) [93] .

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

или вызове . Аренда записи также посылает сигнал при открытии файла для чтения [94] 22. Аренды файлов работают только для модификаций, внесенных в файл той же системой, которая владеет арендой. Если файл локальный (не файл, доступ к которому возможен через сеть), любой подходящий доступ к файлу инициирует сигнал. Если доступ к файлу возможен через сеть, передачу сигнала вызывают только процессы на одной машине с процессо-арендатором; доступ с любой другой машины удается в случае отсутствия аренды.

Системный вызов

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

Аренда создается или освобождается в зависимости от значения последнего параметра, передаваемого в

; создает аренду чтения, — аренду записи, a освобождает любую аренду, которая может существовать. Если запрашивается новая аренда, она заменяет любую существующую аренду. В случае ошибки возвращается отрицательное число; ноль или положительное число свидетельствуют об успехе операции [95] .

Возвращается тип аренды, существующей в настоящий момент для файла (

, или ).

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

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

Использование

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