Чтобы показать несомненную проблемность кода, можно заменить закомментированную строку ОТРЕЗОК ВРЕМЕНИ НА СБОЙ в листинге 5.1 фрагментом кода, создающим искусственную задержку между проверкой существования файла и созданием файла:
Рис. 5.1.
printf("[PID %ld] File \"%s\" doesn't exist yet\n", (long) getpid(), argv[1]);
if (argc > 2) { /* Задержка между проверкой и созданием */
sleep(5); /* Приостановка выполнения на 5 секунд */
printf("[PID %ld] Done sleeping\n", (long) getpid());
}
Библиотечная функция sleep() приостанавливает выполнение процесса на указанное количество секунд. Эта функция рассматривается в разделе 23.4.
Если одновременно запустить два экземпляра программы, показанной в листинге 5.1, станет видно, что они обе утверждают, что создали файл эксклюзивно:
$ ./bad_exclusive_open tfile sleep &
[PID 3317] File "tfile" doesn't exist yet
[1] 3317
$ ./bad_exclusive_open tfile
[PID 3318] File "tfile" doesn't exist yet
[PID 3318] Created file "tfile" exclusively
$ [PID 3317] Done sleeping
[PID 3317] Created file "tfile" exclusively
В предпоследней строке показанного экранного вывода видно, как смешались символ приглашения оболочки ко вводу ($) и вывод из первого экземляра тестовой программы.
Оба процесса утверждают о создании файла, потому что код первого процесса был прерван между проверкой на существование файла и созданием файла. Применение одного вызова open() с указанием флагов O_CREAT и O_EXCL предотвращает подобную ситуацию, гарантируя, что этапы проверки и создания выполняются как единая атомарная (то есть непрерывная) операция.
Второй пример необходимости атомарности касается добавления данных к одному и тому же файлу сразу несколькими процессами (например, к глобальному журнальному файлу). Для этого можно было бы рассмотреть возможность использования каждым из записывающих процессов следующего фрагмента кода:
if (lseek(fd, 0, SEEK_END) == -1)
errExit("lseek");
if (write(fd, buf, len)!= len)
fatal("Partial/failed write");
Но в этом коде, как и в предыдущем примере, есть точно такой же недостаток. Если первый выполняющий код процесс будет прерван между вызовами lseek() и write() вторым процессом, делающим то же самое, тогда оба процесса установят свои файловые смещения перед записью на одно и то же место, и, когда первому процессу диспетчер снова выделит процессорное время, он перепишет данные, уже записанные вторым процессом. Здесь опять возникает состояние гонки, поскольку результаты зависят от порядка диспетчеризации двух процессов.
Избежать возникновения данной проблемы можно при условии, что смещение на следующий байт за конец файла и операция записи будут происходить атомарно. Именно это гарантирует открытие файла с флагом O_APPEND.
В некоторых файловых системах (например, в NFS) флаг O_APPEND не поддерживается. В таком случае ядро возвращается к показанной выше неатомарной последовательности вызовов с возможностью описанного выше повреждения файла.
Системный вызов fcntl() может выполнять операции управления, используя дескриптор открытого файла.
#include
int fcntl(int
Значение, возвращаемое при успешном завершении, зависит от значения cmd или равно –1 при сбое
Аргумент cmd может указывать на широкий диапазон операций. Одни из них будут рассмотрены в следующих разделах, а до других мы доберемся лишь в последующих главах.
Многоточие показывает, что третий аргумент fcntl() может быть различных типов или же может быть опущен. Ядро использует значение аргумента cmd для определения типа данных (если таковой будет), который следует ожидать для этого аргумента.
Один из примеров использования fcntl() — извлечение или изменение флагов режима доступа и состояния открытого файла. (Это значения, установленные аргументом flags, указанным в вызове open().) Чтобы извлечь эти установки, для cmd указывается значение F_GETFL:
int flags, accessMode;
flags = fcntl(fd, F_GETFL); /* Третий аргумент не требуется */
if (flags == -1)
errExit("fcntl");
После этого фрагмента кода можно проверить, был ли файл открыт для синхронизированной записи:
if (flags & O_SYNC)
printf("записи синхронизированы \n");
В SUSv3 требуется, чтобы открытому файлу соответствовали лишь те флаги, которые были указаны при системном вызове open() или последующих операциях F_SETFL вызова fcntl(). В Linux есть единственное отклонение от этого требования: если приложение было скомпилировано с использованием одного из подходов, рассматриваемых в разделе 5.10 для открытия больших файлов, то среди флагов, извлекаемых операцией F_GETFL всегда будет установлен O_LARGEFILE.