Следствия принятой логики блокирования файлов

Невзирая на всю естественность логики блокирования файлов, представленной в таблицах 3.1 и 3.2, последствия ее внедрения возможно окажутся вам внезапными и вызвать на 1-ый взор не поддающиеся объяснению конфигурации в поведении программки. Некие вероятные примеры этого приводятся ниже.

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

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

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

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

Внедрение блокирования файлов

Рассмотрение примеров блокирования файлов мы отложим до главы 6, в какой дискуссируется управление процессами. В программках 4.2, 6.4, 6.5 и 6.6 блокирование файлов употребляется для обеспечения того, чтоб в каждый момент времени изменять файл мог только один процесс.

В UNIX блокирование Следствия принятой логики блокирования файлов файлов является уведомляющим (advisory); выполнение процесса ввода/вывода может длиться даже в этом случае, если попытка получения блокировки оказалась неудачной (логика, отраженная в табл. 3.1, действует и в данном случае). Это обеспечивает в UNIX возможность блокирования файлов взаимодействующими процессами, но хоть какой другой процесс может нарушить описанный протокол Следствия принятой логики блокирования файлов.

Для получения уведомляющей блокировки употребляются характеристики, указываемые при вызове функции fcntl. Допустимыми командами (2-ой параметр) являются 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. Окно редактора реестра

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

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

Ключи реестра

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

• HKEY_LOCAL Следствия принятой логики блокирования файлов_MACHINE. В этом разделе хранится информация об оборудовании локального компьютера и установленном на нем программном обеспечении. Информация об установленном программном обеспечении обычно создается в подразделах (subkeys) в виде: SOFTWARE\НазваниеКомпании\НазваниеПродукта\Версия.

• HKEY_USERS. В этом разделе хранится информация о настройке пользовательских конфигураций.

• HKEY_CURRENT_CONFIG. В Следствия принятой логики блокирования файлов этом разделе хранятся текущие опции таких характеристик, как разрешение монитора либо гарнитура шрифта.

• HKEY_CLASSES_ROOT. В этом разделе содержатся подчиненные записи, устанавливающие соответствие меж названиями файлов и классами, также приложениями, применяемыми оболочкой для доступа к объектам, имена которых имеют определенные расширения. В этот раздел также входят все подразделы, нужные для Следствия принятой логики блокирования файлов функционирования модели компонентных объектов (Component Object Model — СОМ), разработанной компанией Microsoft.

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


slovar-geograficheskih-nazvanij-tajmir-yaponskie-ostrova.html
slovar-i-graficheskie-oboznacheniya.html
slovar-imen-sobstvennih.html