Кооперация процессов при работе с файлами

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

Например, если несколько пользователей одновременно редактиру­ют какой-либо файл и не принято специальных мер, то результат будет непредсказуем и зависит оттого, в каком порядке осуществлялись записи в файл. Между двумя операциями read одного процесса другой процесс может модифицировать данные, что для многих приложений неприемле­мо. Простейшее решение данной проблемы — предоставить возможность одному из процессов захватить файл, то есть блокировать доступ к разде­ляемому файлу других процессов на все время, пока файл остается откры­тым для данного процесса. Однако это было бы недостаточно гибко и не соответствовало бы характеру поставленной задачи.

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

Системный вызов, позволяющий установить и проверить блокиров­ки на файл, является неотъемлемым атрибутом современных многополь­зовательских ОС. В принципе, было бы логично связать синхронизацию доступа к файлу как к единому целому с системным вызовом open (т. е., например, открытие файла в режиме записи или обновления могло бы оз­начать его монопольную блокировку соответствующим процессом, а от­крытие в режиме чтения — совместную блокировку). Так поступают вомногих операционных системах (начиная с ОС Multics). В ОС Unix это не так, что имеет исторические причины.

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

Более тонкий подход заключается в прозрачной для пользователя блокировке отдельных структур ядра, отвечающих за работу с файлами части пользовательских данных. Например, в ОС Unix во время систем­ного вызова, осуществляющего ту или иную операцию с файлом, как пра­вило, происходит блокирование индексного узла, содержащего адреса блоков данных файла. Может показаться, что организация блокировок или запрета более чем одному процессу работать с файлом во время вы­полнения системного вызова является излишней, так как в подавляющем большинстве случаев выполнение системных вызовов и так не прерыва­ется, то есть ядро работает в условиях невытесняющей многозадачности. Однако в данном случае это не совсем так. Операции чтения и записи за­нимают продолжительное время и лишь инициируются центральным процессором, а осуществляются по независимым каналам, поэтому уста­новка блокировок на время системного вызова является необходимой гарантией атомарности операций чтения и записи. На практике оказывает­ся достаточным заблокировать один из буферов кэша диска, в заголовке которого ведется список процессов, ожидающих освобождения данного буфера. Таким образом, в соответствии с семантикой Unix изменения, сделанные одним пользователем, немедленно становятся «видны» друго­му пользователю, который держит данный файл открытым одновременно с первым.

При возникновении классического тупика между процессами.

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

Понятие о pipe. Системный вызов pipe()

Наиболее простым способом для передачи информации с помощью потоковой модели между различными процессами или даже внутри одно­го процесса в операционной системе UNIX является pipe (канал, труба, конвейер).

Важное отличие pip’a от файла заключается в том, что прочитанная информация немедленно удаляется из него и не может быть прочитана повторно.

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

Понятно, что если бы все достоинство pip'oвсводилось к замене функции копирования из памяти в память внутри одного процесса на пе­ресылку информации через операционную систему, то овчинка не стоила бы выделки. Однако таблица открытых файлов наследуется процессом-ребенком при порождении нового процесса системным вызовом fork() и входит в состав неизменяемой части системного контекста процесса при системном вызове ехес() (за исключением тех потоков данных, для файловых дескрипторов которых был специальными средствами выстав­лен признак, побуждающий операционную систему закрыть их при вы­полнении ехес(). Это обстоятельство позволяет организовать передачу информации через pipe между родственными процессами, имеющими общего праро­дителя, создавшего pipe.