41)Критичний ресурс. Критична секція. Використання спільної змінної.

Пусть переменная Status, которая определена в области памяти доступной нескольким процессам, задает состояние критической секции (занята, свободна). Вход в критическую секцию процесса возможен только в том случае, если она свободна.

Недостатки метода:

- операторы while (Status == Busy) проверки состояния критической секции и Status= Busy установки этого состояния должны выполняться как один оператор.

- Не определен порядок выполнения процессов, в реальных задачах часто необходимо зафиксировать этот порядок.

- Если квант времени выделен процессу, который не может выполняться сейчас, процессор выполняет цикл ожидания вместо переключения на другой процесс.

Первый недостаток устраняется, выключением прерываний на время проверки и установки значения. Современные процессоры также имеют в списке команд такие, которые позволяют проверять и изменять значение переменной одной командой.

42)Критичний ресурс. Критична секція. Почергове виконання критичної секції.

Пусть процессы должны выполнять КС, причем первым должен выполнить КС первый процесс. Определим общую для обоих процессов переменную, куда вначале запишем номер процесса который должен первым выполнить КС.

Недостаток метода:

Если процесс 1 выполняется на более быстром процессоре, то он не сможет два раза подряд выполнить свою критическую секцию. По-прежнему процессор простаивает до завершения кванта времени, если КС не может бать выполнена.

43)Критичний ресурс. Критична секція. Алгоритм Деккера.

Используем 3 общих переменных для процессов c[0] – истина, если выполняется КС первого процесса; c[1] – истина, если выполняется КС второго процесса; переменная OtherProcessNumber задает номер неактивного процесса. Начальная инициализация переменных:

bool c[2] = {false, false};

int OtherProcessNumber = 0;

// Код для процесса 1 с критическим участком кода

// Установка переменных для первого процесса

int i=0; j = 1 – i;

c[i] = true; OtherProcessNumber = j;

// Ждем пока критическую секцию выполняет второй процесс

while (c[j] && OtherProcessNumber == j);

// Критическа секция

…

c[i] = false;

Для второго процесса переменная i = 1. Для решения проблемы простоя процессора в случае необходимости ожидания завершения выполнения КС другим процессом используется блокирование, выполнение которого не может быть продолжено. Блокирование процесса выполняет ОС. В этом случае квант времени процессора передается готовому процессу. В следующих разделах предполагается, что процессы, которые не могут выполняться, блокируются.

44)Поняття синхронізації. Виявлення та запобігання тупиків (блокувань).

Проблема синхронизации возникает для зависимых процессов, когда выполнение одних процессов зависит от выполнения других. Например, если один процесс пишет запись, а второй ее читает, то до завершения создания записи читать ее не имеет смысла.

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

1 способ: каждый процесс вначале запрашивает все необходимые ему ресурсы. Процесс запускается только в том случае, если все необходимые ресурсы есть в наличии (в этом случае тупик никогда не возникнет). Недостатки способа – ресурсы выделяются задолго до их использования, что ограничивает использования этих ресурсов другими процессами.

2 способ: Все ресурсы делятся на классы. К классу с наибольшим номером относятся наиболее критические ресурсы, которые должны выделяться кратковременно. Процессу выделяется ресурс из заданного класса только в том случае, если этот ресурс есть в наличии и если процесс освободил все ресурсы с большими номерами.

3 способ: алгоритм аналогичен алгоритму принятия решения по выпуску займа. Такое решение приводит к тому, что обнаружение опасных ситуаций может занимать много времени, поэтому можно использовать их автоматическое обнаружение . Если выполнение критической секции превышает заданный интервал времени, выполнение завершается, а общий ресурс восстанавливается таким, каким он был до входа в КС.