Харт Джонсон М.
Шрифт:
Каждый успешный вызов функции LockFileEx должен сопровождаться последующим вызовом функции UnlockFileEx (то же самое касается и пары функций LockFile и UnlockFile). Если программа не позаботится о снятии блокировки или будет удерживать ее в течение большего, чем это необходимо, времени, другие программы либо вовсе не смогут работать, либо будут вынуждены простаивать. Поэтому уже на стадии проектирования и реализации программ необходимо очень тщательно следить за тем, чтобы снятие блокировки осуществлялось сразу же после того, как необходимость в ней отпала, а логика работы программ не позволяла оставлять невыполненными необходимые операции разблокирования файлов.
Одним из способов, гарантирующих своевременное разблокирования файлов, является использование дескрипторов завершения (termination handlers), которые описаны в главе 4.
Следствия принятой логики блокирования файлов
Несмотря на всю естественность логики блокирования файлов, представленной в таблицах 3.1 и 3.2, последствия ее применения могут оказаться для вас неожиданными и вызвать на первый взгляд необъяснимые изменения в поведении программы. Некоторые возможные примеры этого приводятся ниже.
• Предположим, что процессы А и В периодически приобретают разделяемые блокировки файла, а процесс С блокируется при попытке получения монопольной блокировки того же файла после того, как процесс А стал владельцем собственной разделяемой блокировки. В этих условиях процесс В может получить свою разделяемую блокировку, но процесс С будет оставаться блокированным даже после того, как процесс А снимет свою блокировку файла. Процесс С будет оставаться блокированным до тех пор, пока все процессы не снимут свои блокировки, даже если они были получены уже тогда, когда процесс С пребывал в блокированном состоянии. Согласно этому сценарию процесс С может оставаться блокированным сколь угодно долго, тогда как другие процессы сохраняют возможность управления своими разделяемыми блокировками.
• Предположим, что процесс А стал владельцем разделяемой блокировки файла, а процесс В пытается осуществить считывание файла без предварительного приобретения разделяемой блокировки. В этой ситуации чтение может быть успешно осуществлено даже несмотря на то, что процесс, выполняющий чтение, не владеет ни одной блокировкой данного файла, поскольку операция чтения не вступает в конфликт с существующей разделяемой блокировкой.
• Все, о чем говорилось выше, относится не только к блокировке файла в целом, но и к блокировке отдельного его участка.
• Процессы чтения и записи вполне могут успешно завершить часть своего запроса, прежде чем возникнет конфликт с существующей блокировкой. В этом случае функции чтения и записи возвратят значения FALSE, а значение счетчика переданных байтов окажется меньше затребованного.
Рассмотрение примеров блокирования файлов мы отложим до главы 6, в которой обсуждается управление процессами. В программах 4.2, 6.4, 6.5 и 6.6 блокирование файлов используется для обеспечения того, чтобы в каждый момент времени изменять файл мог только один процесс.
В UNIX блокирование файлов является уведомляющим (advisory); выполнение процесса ввода/вывода может продолжаться даже в том случае, если попытка получения блокировки оказалась неудачной (логика, отраженная в табл. 3.1, действует и в этом случае). Это обеспечивает в UNIX возможность блокирования файлов взаимодействующими процессами, но любой другой процесс может нарушить описанный протокол.
Для получения уведомляющей блокировки используются параметры, указываемые при вызове функции fcntl. Допустимыми командами (второй параметр) являются F_SETLK, F_SETLKW и F_GETLK. Информация о типе блокировки (F_RDLCK, F_WRLCK или F_UNLCK) и блокируемой области содержится в дополнительной структуре данных.
Помимо этого, в некоторых UNIX-системах доступна обязательная (mandatory) блокировка, обеспечиваемая путем определения групповых полномочий для файла с помощью команды chmode.
Блокирование файлов в UNIX имеет много особенностей. Например, блокировки наследуются при выполнении вызова функции exec.
Блокирование файлов библиотекой С не поддерживается, но в Visual C++ обеспечивается поддержка нестандартных расширений механизма блокирования.
Реестр
Реестр — это централизованная иерархическая база данных, хранящая информацию о параметрах конфигурации операционной системы и установленных приложений. Доступ к реестру осуществляется через разделы, или ключи, реестра (registry keys), играющие ту же роль, что и каталоги в файловой системе. Раздел может содержать подразделы или пары "имя-значение", в которых между именем и значением существует примерно та же взаимосвязь, что и между именами файлов и их содержимым.
Пользователь или системный администратор может просматривать и изменять содержимое реестра, пользуясь редактором реестра, для запуска которого необходимо выполнить команду REGEDIT. Реестром можно управлять также из программ, используя функции API реестра, описанные в данном разделе.
Примечание
Программирование реестра обсуждается в данной главе по той причине, что решаемая при этом задача весьма напоминает обработку файлов, а также потому, что оно играет важную роль в некоторых, хотя и не во всех, приложениях. Соответствующий пример будет получен путем несложного изменения программы lsW. Вместе с тем, данный раздел вполне мог бы стать небольшой отдельной главой. Поэтому читатели, для которых программирование реестра не представляет непосредственного интереса, могут пропустить этот раздел, чтобы вернуться к нему впоследствии, если это окажется необходимым.