The design of the UNIX Operating System 84 страница
Допускается два варианта синхронизации : с ожиданием, когда требование блокировки может привести к откладыванию процесса до того момента, когда это требование может быть удовлетворено, и без ожида-ния, когда процесс немедленно оповещается об удовлетворении требования блокировки или о невозмож-ности ее удовлетворения в данный момент.
Установленные блокировки относятся только к тому процессу, который их установил, и не наследуются процессами- потомками этого процесса. Более того, даже если некоторый процесс пользуется синхрони-зационными возможностями системного вызова fcntl, другие процессы по-прежнему могут работать с
|
|
|
| Основы операционных систем | 121 |
тем файлом без всякой синхронизации. Другими словами, это дело группы процессов, совместно исполь-зующих файл, - договориться о способе синхронизации параллельного доступа.
|
|
|
Более тонкий подход заключается в прозрачной для пользователя блокировке отдельных структур ядра, отвечающих за работу с файлами части пользовательских данных. Например, в ОС Unix во время сис-темного вызова, осуществляющего ту или иную операцию с файлом, как правило, происходит блокиро - вание индексного узла, содержащего адреса блоков данных файла. Может показаться, что организация блокировок или запрета более чем одному процессу работать с файлом во время выполнения системного вызова является излишней, так как в подавляющем большинстве случаев выполнение системных вызовов
|
|
|
и так не прерывается, то есть ядро работает в условиях невытесняющей многозадачности. Однако в дан-ном случае это не совсем так. Операции чтения и записи занимают продолжительное время и лишь ини-циируются центральным процессором, а осуществляются по независимым каналам, поэтому установка блокировок на время системного вызова является необходимой гарантией атомарности операций чтения
|
|
|
и записи. На практике оказывается достаточным заблокировать один из буферов кэша диска, в заголовке которого ведется список процессов, ожидающих освобождения данного буфера. Таким образом, в соот-ветствии с семантикой Unix изменения, сделанные одним пользователем, немедленно становятся "вид-ны" другому пользователю, который держит данный файл открытым одновременно с первым.
Примеры разрешения коллизий и тупиковых ситуаций
Логика работы системы в сложных ситуациях может проиллюстрировать особенности организации мультидоступа.
Рассмотрим в качестве примера образование потенциального тупика при создании связи (link), когда разрешен совместный доступ к файлу [Bach, 1986].
Два процесса, выполняющие одновременно следующие функции:
процесс A: link("a/b/c/d","e/f/g"); процесс B: link("e/f","a/b/c/d/ee");
могут зайти в тупик. Предположим, что процесс A обнаружил индекс файла "a/b/c/d" в тот самый мо-мент, когда процесс B обнаружил индекс файла "e/f". Фраза "в тот же самый момент" означает, что сис-темой достигнуто состояние, при котором каждый процесс получил искомый индекс. Когда же теперь процесс A попытается получить индекс файла "e/f", он приостановит свое выполнение до тех пор, пока индекс файла "f" не освободится . В то же время процесс B пытается получить индекс каталога "a/b/c/d" и приостанавливается в ожидании освобождения индекса файла "d". Процесс A будет удерживать заблоки-рованным индекс, нужный процессу B, а процесс B, в свою очередь, будет удерживать заблокированным индекс, необходимый процессу A.
Дата добавления: 2021-01-21; просмотров: 121; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!