Министерство Образования и Науки Российской Федерации
Федеральное Агентство по Образованию
Государственно Образовательное Учреждение
Высшего Профессионального Образования
Новосибирский Государственный Технический Университет
Кафедра Вычислительной Техники
Лабораторная работа №5
По дисциплине «Операционные Системы»
Управление процессами. Семафорные операции.
Факультет: АВТ
Группа: АМ-411
Студент:
Преподаватель:
Новосибирск, 2007
Цель работы:
Целью лабораторной работы является изучение семафорных операций, используемых при разрешении конфликтов между процессами.
Сравнение семафоров в UNIX и WINDOWS NT
В отличие от общепринятого понятия – семафор, который может быть либо открыт, разрешая движение, либо закрыт, запрещая его, семафоры в операционной системе Microsoft Windows NT действуют более сложным образом.
Семафор может находиться в отмеченном или неотмеченном состоянии. Приложение выполняет ожидание для семафора при помощи таких функций, как WaitForSingleObject или WaitForMultipleObject. Если семафор находится в неотмеченном состоянии, задача, вызвавшая для него функцию WaitForSingleObject, находится в состоянии ожидания. Когда же состояние семафора становится отмеченным, работа задачи возобновляется.
С каждым семафором связывается счетчик, начальное и максимальные значения которого задаются при создании семафора. Значение этого счетчика уменьшается, когда задача вызывает для семафора функцию WaitForSingleObject или WaitForMultipleObject, и увеличивается при вызове другой, специально предназначенной для этого функции ReleaseSemaphore.
Если значение счетчика семафора равно нулю, он находится в неотмеченном состоянии. Если же это значение больше нуля, семафор переходит в отмеченное состояние.
Пусть, например, приложение создало семафор, указав для него максимальное значение счетчика, равное трем. Пусть начальное значение этого счетчика также будет равно трем.
Если в этой ситуации несколько запускаемых по очереди задач будут выполнять с помощью функции WaitForSingleObject ожидание семафора, то первые три запущенные задачи будут работать, а все остальные перейдут в состояние ожидания. Это связано с тем, что первые три вызова функции WaitForSingleObject приведут к последовательному уменьшению значения счетчика семафора до нуля, в результате чего семафор переключится в неотмеченное состояние.
Задача, запущенная четвертой, вызовет функцию WaitForSingleObject для неотмеченного семафора, в результате чего она будет ждать. Точно также, задачи, запущенные после запуска четвертой задачи, будут выполнять ожидание для того же семафора.
Это ожидание продлится до тех пор, пока одна из первых трех задач не освободит семафор, увеличив его счетчик на единицу вызовом специальной функции. Сразу после этого будет запущена одна из задач, ожидающих наш семафор.
Семафор в Unix состоит из следующих элементов.
1. Значение семафора.
2. Идентификатор последнего из процессов, работавших с семафором.
3. Количество процессов, ожидающих увеличения значения семафора.
4. Количество процессов, ожидающих момента, когда значение семафора станет равным 0.
Для создания набора семафоров и получения доступа к ним используется системная функция semget, для выполнения различных управляющих операций над набором – функция semctl, для работы со значениями семафоров – функция semop.
В результате выполнения функции semget ядро выделяет запись, указывающую на массив семафоров и содержащую счетчик. В записи также хранится количество семафоров в массиве, время последнего выполнения функций semop и semctl.
Синтаксис вызова системной функции semop:
oldval = semop(id, oplist, count), где id – дескриптор, возвращаемый функцией semget, oplist – указатель на список операций, count – размер списка. Возвращаемое функцией значение oldval является прежним значением семафора, над которым производилась операция.
Каждый элемент списка операций имеет следующий формат:
- номер семафора, идентифицирующий элемент массива семафоров, над которым выполняется операция;
- код операции;
- флаги.
Ядро считывает список операций oplist из адресного пространства задачи и проверяет корректность номеров семафоров, а также наличие у процесса необходимых разрешений на чтение и корректировку семафоров. Если таких разрешений не имеется, системная функция завершается неудачно. Если ядру приходится приостанавливать свою работу при обращении к списку операций, оно возвращает семафорам их прежние значения и находится в состоянии приостанова до наступления ожидаемого события, после чего системная функция запускается вновь. Поскольку ядро хранит коды операций над семафорами в глобальном списке, оно вновь считывает этот список из пространства задачи, когда перезапускает системную функцию. Таким образом, операции выполняются комплексно – или все за один сеанс или ни одной.
Ядро меняет значение семафора в зависимости от кода операции. Если код операции имеет положительное значение, ядро увеличивает значение семафора и выводит из состояния приостанова все процессы, ожидающие наступления этого события. Если код операции равен 0, ядро проверяет значение семафора: если оно равно 0, ядро переходит к выполнению других операций; в противном случае ядро увеличивает число приостановленных процессов, ожидающих, когда значение семафора станет нулевым, и «засыпает». Если код операции имеет отрицательное значение и если его абсолютное значение не превышает значение семафора, ядро прибавляет код операции к значению семафора. Если результат равен 0, ядро выводит из состояния приостанова все процессы, ожидающие обнуления значения семафора. Если результат меньше абсолютного значения кода операции, ядро приостанавливает процесс до тех пор, пока значение семафора не увеличится.
Выполнение лабораторной работы:
Исходные данные:
- на процессоре одновременно развивается 6 задач интенсивность обращения к ресурсам – 40%
По исходным данным получена временная диаграмма, которая отображает нахождение данных задач на процессоре, в критической секции или блокирование по причине занятости необходимого ресурса. Временная диаграмма приведена на рисунке 1.
Рис. 1 Временная диаграмма, полученная в результате моделирования
Анализируя временную диаграмму, составим таблицу:
Процесс | tty | winch | flop | Scs | Sблок | Scpu. факт | |
0 | - | 35 | - | 15 | 50 | 0 | 53,05 |
1 | 18 | - | 72 | - | 90 | 35 | 45,13 |
2 | 44 | - | 40 | - | 84 | 0 | 35,30 |
3 | - | - | - | 104 | 104 | 12 | 32,55 |
4 | 54 | - | - | 24 | 78 | 27 | 72,53 |
5 | 47 | 61 | - | - | 108 | 0 | 66,43 |
Пример расчета для процесса № 0:
1) Scs = tty + flop = 35 + 15 = 50
2) Sблок = 0
3) Scpu. факт =
При переходе на уровень диспетчеризации необходимо рассчитывать время работы диспетчера: 
, где ki – коэффициент мультипрограммирования i-го интервала, 
- время диспетчера, затраченное на 1 процесс на i-ом интервале.
Переход на уровень диспетчеризации приведен в приложении.
Вывод:
В ходе лабораторной работы моделировалась работа операционной системы при наличии определенного числа задач (процессов) и ограниченного числа ресурсов. Каждый процесс в какой-то, известный только ему, момент времени требует использования определенного ресурса. Ресурс используется процессом безраздельно. Если какой-нибудь другой процесс в это время пытается обратиться к этому же ресурсу, он блокируется до того момента, пока первый процесс не закончит работу с этим ресурсом. Для реализации такого алгоритма работы используются семафоры.
Семафоры – целочисленные объекты, для которых определены две элементарные операции – P и V. Операция P заключается в уменьшении значения семафора, операция V – в увеличении этого значения.
За каждым ресурсом закреплен семафор, инициализированный значением 1, т. к. в данной работе только один процесс может использовать ресурс безраздельно. Вообще, семафоры позволяют обеспечить доступ к ресурсу для заранее определенного, ограниченного приложением количества задач. Все остальные задачи, пытающиеся получить доступ сверх установленного лимита, будут переведены при этом в состояние ожидания до тех пор, пока какая-либо задача, получившая доступ к ресурсу раньше, не освободит ресурс, связанный с данным семафором.
По заданным параметрам, мы получили временную диаграмму, показывающую нахождения процессов в разных состояниях. Перешли от уровня выполнения процессов на уровень диспетчеризации.
Граничные значения на временных диаграммах отличаются на, что можно объяснить временными затратами на работу диспетчера.
