7 Цели и необходимость синхронизации процессов и потоков. Критическая секция. Блокирующие переменные. Семафоры Дейкстры.

Существует необходимость взаимодействия процессов. Даже в случае наличия независимых процессов, не предназначенных для выполнения общей задачи (па-кетные задания, интерактивные сессии), операционная система должна решать вопросы конкурентного использования ресурсов. Например, два независимых приложения могут запросить доступ к одному диску или порту. Поэтому необхо-димо правильно организованное взаимодействие между процессамиДля успешного взаимодействия процессов необходимы два механизма: o Синхронизация. Процессам, выполняющим общую задачу, нужно ЖДАТЬ друг друга и СИГНАЛИЗИРОВАТЬ друг другу.

o Взаимное исключение. Конкурирующие процессы должны ЖДАТЬ освобож-дения общего ресурса и СИГНАЛИЗИРОВАТЬ об окончании его использования.

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

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

Для синхронизации потоков одного процесса прикладной программист может использовать глобальные блокирующие переменные. С этими переменными, к ко-торым все потоки процесса имеют прямой доступ, программист работает, не об-ращаясь к системным вызовам ОС. овершенно иным образом подошел к про-блеме взаимного исключения великий голландский ученый Э.Дейкстра (E.Dijkstra, 1966). Он предложил использовать новый вид программных объектов – семафоры. Здесь мы рассмотрим их простейший вариант – двоичные семафо-ры, они же мьютексы (mutex, от слов MUTual EXclusion – взаимное исключе-ние).

Двоичным семафором называется переменная S, которая может принимать зна-чения 0 и 1 и для которой определены только две операции. · P(S) – операция за-нятия (закрытия) семафора. Она ожидает, пока значение S не станет равным 1, и, как только это случится, присваивает S значение 0 и завершает свое выполнение. Очень важно: операция P по определению неделима, т.е. между проверкой и при-сваиванием не может вклиниться другой процесс, который бы изменил значение S.

8 Тупики. Восстановление после тупиков. Предотвращение тупиков за счет нарушения условий возникновения.

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

Восстановление после тупиков В тех же случаях, когда тупиковую ситуацию не удалось предотвратить, важно быстро и точно ее распознать, поскольку блокированные потоки не выполняют никакой полезной работы. Если тупиковая ситуация образована множеством потоков, занимающих массу ресурсов, распознавание тупика является нетривиальной задачей. Существуют формальные, программно-реализованные методы распознавания тупиков, основанные на ведении таблиц распределения ресурсов и таблиц запросов к занятым ресурсам. Анализ этих таблиц позволяет обнаружить взаимные блокировки. Если же тупиковая ситуация возникла, то не обязательно снимать с выполнения все заблокированные потоки. Можно снять только часть из них, освободив ресурсы, ожидаемые остальными потоками, можно вернуть некоторые потоки в область подкачки, можно совершить «откат» некоторых потоков до так называемой контроль-ной точки, в которой запоминается вся информация, необходимая для восстановления выполнения программы с данного места. Контрольные точки расставляются в программе в тех местах, после которых возможно возникновение тупика.