Лекции по предмету Операционные системы
тия с выполнения активной задачи, запоминает ее
контекст, выбирает из очереди готовых задач следующую и запускает ее на
выполнение, загружая ее контекст.
При невытесняющей многозадачности механизм планирования распределен между
системой и прикладными программами. Прикладная программа, получив
управление от операционной системы, сама определяет момент завершения своей
очередной итерации и передает управление ОС с помощью какого-либо
системного вызова, а ОС формирует очереди задач и выбирает в соответствии с
некоторым алгоритмом (например, с учетом приоритетов) следующую задачу на
выполнение. Такой механизм создает проблемы как для пользователей, так и
для разработчиков.
Для пользователей это означает, что управление системой теряется на
произвольный период времени, который определяется приложением (а не
пользователем). Если приложение тратит слишком много времени на выполнение
какой-либо работы, например, на форматирование диска, пользователь не может
переключиться с этой задачи на другую задачу, например, на текстовый
редактор, в то время как форматирование продолжалось бы в фоновом режиме.
Эта ситуация нежелательна, так как пользователи обычно не хотят долго
ждать, когда машина завершит свою задачу.
Поэтому разработчики приложений для non-preemptive операционной среды,
возлагая на себя функции планировщика, должны создавать приложения так,
чтобы они выполняли свои задачи небольшими частями. Например, программа
форматирования может отформатировать одну дорожку дискеты и вернуть
управление системе. После выполнения других задач система возвратит
управление программе форматирования, чтобы та отформатировала следующую
дорожку. Подобный метод разделения времени между задачами работает, но он
существенно затрудняет разработку программ и предъявляет повышенные
требования к квалификации программиста. Программист должен обеспечить
"дружественное" отношение своей программы к другим выполняемым одновременно
с ней программам, достаточно часто отдавая им управление. Крайним
проявлением "недружественности" приложения является его зависание, которое
приводит к общему краху системы. В системах с вытесняющей многозадачностью
такие ситуации, как правило, исключены, так как центральный планирующий
механизм снимет зависшую задачу с выполнения.
Однако распределение функций планировщика между системой и приложениями не
всегда является недостатком, а при определенных условиях может быть и
преимуществом, потому что дает возможность разработчику приложений самому
проектировать алгоритм планирования, наиболее подходящий для данного
фиксированного набора задач. Так как разработчик сам определяет в программе
момент времени отдачи управления, то при этом исключаются нерациональные
прерывания программ в "неудобные" для них моменты времени. Кроме того,
легко разрешаются проблемы совместного использования данных: задача во
время каждой итерации использует их монопольно и уверена, что на протяжении
этого периода никто другой не изменит эти данные. Существенным
преимуществом non-preemptive систем является более высокая скорость
переключения с задачи на задачу.
Примером эффективного использования невытесняющей многозадачности является
файл-сервер NetWare, в котором, в значительной степени благодаря этому,
достигнута высокая скорость выполнения файловых операций. Менее удачным
оказалось использование невытесняющей многозадачности в операционной среде
Windows 3.х.
Однако почти во всех современных операционных системах, ориентированных на
высокопроизводительное выполнение приложений (UNIX, Windows NT, OS/2,
VAX/VMS), реализована вытесняющая многозадачность. В последнее время дошла
очередь и до ОС класса настольных систем, например, OS/2 Warp и Windows 95.
Возможно в связи с этим вытесняющую многозадачность часто называют истинной
многозадачностью.
Средства синхронизации и взаимодействия процессов
Проблема синхронизации
Процессам часто нужно взаимодействовать друг с другом, например, один
процесс может передавать данные другому процессу, или несколько процессов
могут обрабатывать данные из общего файла. Во всех этих случаях возникает
проблема синхронизации процессов, которая может решаться приостановкой и
активизацией процессов, организацией очередей, блокированием и
освобождением ресурсов.
[pic]
Рис. 2.3. Пример необходимости синхронизации
Пренебрежение вопросами синхронизации процессов, выполняющихся в режиме
мультипрограммирования, может привести к их неправильной работе или даже к
краху системы. Рассмотрим, например (рисунок 2.3), программу печати файлов
(принт-сервер). Эта программа печатает по очереди все файлы, имена которых
последовательно в порядке поступления записывают в специальный
общедоступный файл "заказов" другие программы. Особая переменная NEXT,
также доступная всем процессам-клиентам, содержит номер первой свободной
для записи имени файла позиции файла "заказов". Процессы-клиенты читают эту
переменную, записывают в соответствующую позицию файла "заказов" имя своего
файла и наращивают значение NEXT на единицу. Предположим, что в некоторый
момент процесс R решил распечатать свой файл, для этого он прочитал
значение переменной NEXT, значение которой для определенности предположим
равным 4. Процесс запомнил это значение, но поместить имя файла не успел,
так как его выполнение было прервано (например, в следствие исчерпания
кванта). Очередной процесс S, желающий распечатать файл, прочитал то же
самое значение переменной NEXT, поместил в четвертую позицию имя своего
файла и нарастил значение переменной на единицу. Когда в очередной раз
управление будет передано процессу R, то он, продолжая свое выполнение, в
полном соответствии со значением текущей свободной позиции, полученным во
время предыдущей итерации, запишет имя файла также в позицию 4, поверх
имени файла процесса S.
Таким образом, процесс S никогда не увидит свой файл распечатанным.
Сложность проблемы синхронизации состоит в нерегулярности возникающих
ситуаций: в предыдущем примере можно представить и другое развитие событий:
были потеряны файлы нескольких процессов или, напротив, не был потерян ни
один файл. В данном случае все определяется взаимными скоростями процессов
и моментами их прерывания. Поэтому отладка взаимодействующих процессов
является сложной задачей. Ситуации подобные той, когда два или более
процессов обрабатывают разделяемые данные, и конечный результат зависит от
соотношения скоростей процессов, называются гонками.
Критическая секция
Важным понятием синхронизации процессов является понятие "критическая
секция" программы. Критическая секция - это часть программы, в которой
осуществляется доступ к разделяемым данным. Чтобы исключить эффект гонок по
отношению к некоторому ресурсу, необходимо обеспечить, чтобы в каждый
момент в критической секции, связанной с этим ресурсом, находился максимум
один процесс. Этот прием называют взаимным исключением.
Простейший способ обеспечить взаимное исключение - позволить процессу,
находящемуся в критической секции, запрещать все прерывания. Однако этот
способ непригоден, так как опасно доверять управление системой
пользовательскому процессу; он может надолго занять процессор, а при крахе
процесса в критической области крах потерпит вся система, потому что
прерывания никогда не будут разрешены.
Другим способом является использование блокирующих переменных. С каждым
разделяемым ресурсом связывается двоичная переменная, которая принимает
значение 1, если ресурс свободен (то есть ни один процесс не находится в
данный момент в критической секции, связанной с данным процессом), и
значение 0, если ресурс занят. На рисунке 2.4 показан фрагмент алгоритма
процесса, использующего для реализации взаимного исключения доступа к
разделяемому ресурсу D блокирующую переменную F(D). Перед входом в
критическую секцию процесс проверяет, свободен ли ресурс D. Если он занят,
то проверка циклически повторяется, если свободен, то значение переменной
F(D) устанавливается в 0, и процесс входит в критическую секцию. После
того, как процесс выполнит все действия с разделяемым ресурсом D, значение
переменной F(D) снова устанавливается равным 1.
[pic]
Рис. 2.4. Реализация критических секций с использованием блокирующих
переменных
Если все процессы написаны с использованием вышеописанных соглашений, то
взаимное исключение гарантируется. Следует заметить, что операция проверки
и установки блокирующей переменной должна быть неделимой. Поясним это.
Пусть в результате проверки переменной процесс определил, что ресурс
свободен, но сразу после этого, не успев установить переменную в 0, был
прерван. За время его приостановки другой процесс занял ресурс, вошел в
свою критическую секцию, но также был прерван, не завершив работы с
разделяемым ресурсом. Когда управление было возвращено первому процессу,
он, считая ресурс свободным, установил признак занятости и начал выполнять
свою критическую секцию. Таким образом был нарушен принцип взаимного
исключения, что потенциально может привести к нежелаемым последствиям. Во
избежание таких ситуаций в системе команд машины желательно иметь единую
команду "проверка-установка", или же реализовывать системными
| |  скачать работу |
Лекции по предмету Операционные системы |
