Все о моделировании в Компас-3D LT
   Главная Статьи Файлы Форум Ссылки Категории новостей
October 06 2024 13:12:37   
Навигация
Главная
Статьи
Файлы
FAQ
Форум
Ссылки
Категории новостей
Обратная связь
Фото галерея
Поиск
Разное
Карта Сайта
Популярные статьи
Что необходимо ... 65535
4.12.1 Професси... 33934
Учимся удалять!... 32221
Примеры, синони... 23538
Просмотр готовы... 22826
Декартовы коорд... 22493
FAST (методика ... 21573
содержание - се... 20857
Просмотр готовы... 19570
Работа с инстру... 15019
Сейчас на сайте
Гостей: 1
На сайте нет зарегистрированных пользователей

Пользователей: 9,955
новичок: Logyattella
Друзья сайта
Ramblers Top100
Рейтинг@Mail.ru

Реклама
Выполняем курсовые и лабораторные по разным языкам программирования
Подробнее - курсовые и лабораторные на заказ по Delphi
Turbo Pascal, Assembler, C, C++, C#, Visual Basic, Java, GPSS, Prolog
5.16.2 Поводы для конкуренции
Поводов для конкуренции при выполнении системной функции unlink очень много, особенно при удалении имен каталогов. Команда rmdir удаляет каталог, убедившись предварительно в том, что в каталоге отсутствуют файлы (она считывает каталог и проверяет значения индексов во всех записях каталога на равенство нулю). Но так как команда rmdir запускается на пользовательском уровне, действия по проверке содержимого каталога и удаления каталога выполняются не так уж просто; система должна переключать контекст между выполнением функций read и unlink. Однако, после того, как команда rmdir обнаружила, что каталог пуст, другой процесс может предпринять попытку создать файл в каталоге функцией creat. Избежать этого пользователи могут только путем использования механизма захвата файла и записи. Тем не менее, раз процесс приступил к выполнению функции unlink, никакой другой процесс не может обратиться к файлу с удаляемой связью, поскольку индексы родительского каталога и файла заблокированы.
Обратимся еще раз к алгоритму функции link и посмотрим, каким образом система снимает с индекса блокировку до завершения выполнения функции. Если бы другой процесс удалил связь файла пока его индекс свободен, он бы тем самым только уменьшил значение счетчика связей; так как значение счетчика связей было увеличено перед удалением связи, это значение останется положительным. Следовательно, файл не может быть удален и система работает надежно. Эта ситуация аналогична той, когда функция unlink вызывается сразу после завершения выполнения функции link.
Другой повод для конкуренции имеет место в том случае, когда один процесс преобразует имя пути поиска файла в индекс файла по алгоритму namei, а другой процесс удаляет каталог, имя которого входит в путь поиска. Допустим, процесс A делает разбор имени «a/ b/c/d» и приостанавливается во время получения индекса для файла «c». Он может приостановиться при попытке заблокировать индекс или при попытке обратиться к дисковому блоку, где этот индекс хранится (см. алгоритмы iget и bread). Если процессу B нужно удалить связь для каталога с именем «c», он может приостановиться по той же самой причине, что и процесс A. Пусть ядро впоследствии решит возобновить процесс B раньше процесса A. Прежде чем процесс A продолжит свое выполнение, процесс B завершится, удалив связь каталога «c» и его содержимое по этой связи. Позднее, процесс A попытается обратиться к несуществующему индексу, который уже был удален. Алгоритм namei, проверяющий в первую очередь неравенство значения счетчика связей нулю, сообщит об ошибке.
Такой проверки, однако, не всегда достаточно, поскольку можно предположить, что какой-нибудь другой процесс создаст в любом месте файловой системы новый каталог и получит тот индекс, который ранее использовался для «c». Процесс A будет заблуждаться, думая, что он обратился к нужному индексу (см. Рисунок 5.32). Как бы то ни было, система сохраняет свою целостность; самое худшее, что может произойти, это обращение не к тому файлу — с возможным нарушением защиты — но соперничества такого рода на практике довольно редки.
Рисунок 5.32. Соперничество процессов за индекс при выполнении функции unlink
#include ‹sys/types.h›
#include ‹sys/stat.h›
#include ‹fcntl.h›
main(argc, argv)
int argc;
char *argv[];
{
int fd;
char buf[1024];
struct stat statbuf;
if (argc != 2) /* нужен параметр */ exit();
fd = open(argv[1], O_RDONLY);
if (fd == -1) /* open завершилась неудачно */ exit();
if (unlink(argv[1]) == -1) /* удалить связь с только что открытым файлом */ exit();
if (stat(argv[1], &statbuf) == -1) /* узнать состояние файла по имени */
printf("stat %s завершилась неудачно\n", argv[1]); /* как и следовало бы */
else printf("stat %s завершилась успешно!\n", argv[1]);
if (fstat(fd, &statbuf) == -1) /* узнать состояние файла по идентификатору */
printf("fstat %s сработала неудачно!\n", argv[1]);
else printf("fstat %s завершилась успешно\n", argv[1]); /* как и следовало бы */
while (read(fd, buf, sizeof(buf)) › 0) /* чтение открытого файла с удаленной связью */
printf("%1024s", buf); /* вывод на печать поля размером 1 Кбайт */
}
Рисунок 5.33. Удаление связи с открытым файлом
Процесс может удалить связь файла в то время, как другому процессу нужно, чтобы файл оставался открытым. (Даже процесс, удаляющий связь, может быть процессом, выполнившим это открытие). Поскольку ядро снимает с индекса блокировку по окончании выполнения функции open, функция unlink завершится успешно. Ядро будет выполнять алгоритм unlink точно так же, как если бы файл не был открыт, и удалит из каталога запись о файле. Теперь по имени удаленной связи к файлу не сможет обратиться никакой другой процесс. Однако, так как системная функция open увеличила значение счетчика ссылок в индексе, ядро не очищает содержимое файла при выполнении алгоритма iput перед завершением функции unlink. Поэтому процесс, открывший файл, может производить над файлом все обычные действия по его дескриптору, включая чтение из файла и запись в файл. Но когда процесс закрывает файл, значение счетчика ссылок в алгоритме iput становится равным 0, и ядро очищает содержимое файла. Короче говоря, процесс, открывший файл, продолжает работу так, как если бы функция unlink не выполнялась, а unlink, в свою очередь, работает так, как если бы файл не был открыт. Другие системные функции также могут продолжать выполняться в процессе, открывшем файл.
В приведенном на Рисунке 5.33 примере процесс открывает файл, указанный в качестве параметра, и затем удаляет связь только что открытого файла. Функция stat завершится неудачно, поскольку первоначальное имя после unlink больше не указывает на файл (предполагается, что тем временем никакой другой процесс не создал файл с тем же именем), но функция fstat завершится успешно, так как она выбирает индекс по дескриптору файла. Процесс выполняет цикл, считывая на каждом шаге по 1024 байта и пересылая файл в стандартный вывод. Когда при чтении будет обнаружен конец файла, процесс завершает работу: после завершения процесса файл перестает существовать. Процессы часто создают временные файлы и сразу же удаляют связь с ними; они могут продолжать ввод-вывод в эти файлы, но имена файлов больше не появляются в иерархии каталогов. Если процесс по какой-либо причине завершается аварийно, он не оставляет от временных файлов никакого следа.
Комментарии
Нет комментариев.
Добавить комментарий
Пожалуйста залогиньтесь для добавления комментария.
Рейтинги
Рейтинг доступен только для пользователей.

Пожалуйста, залогиньтесь или зарегистрируйтесь для голосования.

Нет данных для оценки.
Гость
Имя

Пароль



Вы не зарегистрированны?
Нажмите здесь для регистрации.

Забыли пароль?
Запросите новый здесь.
Случайные статьи
ВТОРОЙ ПРИМЕР
8.1.5 Планирование...
2.3. Представление...
Теоретические осно...
Бенчмаркинг процесса.
Пример домена
Как GPS-приемник о...
Необязательные атр...
Сервисное программ...
Терминология
Применение атрибута
4.1 Структура и ха...
Преодолевая ионосферу
3.6 ВЫВОДЫ
Разъем последовате...
Использование един...
Общая схема вывода
Компьютерные файлы 2
10.1.3 Программы о...
1.2. Классификация...
2.3.2.1 Сигналы те...
Процессор. Память....
9.7. Экспертные оц...
2.6.2.1 Образовани...
Как подключить GPS...
5.4 Информационно...
5.10 CМЕНА ВЛАДЕЛЬ...
Настройки Графичес...
Чтение названий ат...
NAVSTAR
Что такое САПР
Оглавление
Глава 3. ПалмГИС
Отзывы о книге Сет...
7.2.2 Группы проце...
8.2. Планирование...
5.2 READ
8.3.1 Перезапуск ч...
12.5 УЗКИЕ МЕСТА В...
Принцип 1. Как мож...
Мини-чат
Вам необходимо залогиниться.

Нет присланных сообщений.
Copyright © 2009