Системное программирование в среде Windows

Харт Джонсон М.

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

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

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

• Все, о чем говорилось выше, относится не только к блокировке файла в целом, но и к блокировке отдельного его участка.

• Процессы чтения и записи вполне могут успешно завершить часть своего запроса, прежде чем возникнет конфликт с существующей блокировкой. В этом случае функции чтения и записи возвратят значения 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. Вместе с тем, данный раздел вполне мог бы стать небольшой отдельной главой. Поэтому читатели, для которых программирование реестра не представляет непосредственного интереса, могут пропустить этот раздел, чтобы вернуться к нему впоследствии, если это окажется необходимым.

В парах "имя-значение" реестра хранится следующая информация:

• Номер версии операционной системы, номер сборки и информация о зарегистрированном пользователе.

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

• Информация о типе процессоров в системе и их количестве, системной памяти и тому подобное.

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

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

• Информация об установленных службах (глава 13).

• Список соответствий между расширениями имен файлов и ассоциированными с ними исполняемыми программами. Именно эти соответствия используются системой после того, как пользователь щелкнет на пиктограмме какого-либо файла. Например, щелчок на файле с расширением .doc может приводить к запуску текстового редактора Microsoft Word.

• Отображения сетевых адресов на имена, используемые локальным компьютером.

В операционной системе UNIX аналогичная информация хранится в каталоге /etc и файлах, находящихся в основном каталоге пользователя. В Windows 3.1 для этих целей использовались .INI-файлы. Реестр обеспечивает единообразное централизованное хранение всей информации подобного рода. Кроме того, используя средства защиты, описанные в главе 15, можно обеспечить безопасность реестра. 

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

Рис. 3.1. Окно редактора реестра

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