второй блокирует работу потребителя, если в буфере пусто. Первый должен быть инициализирован N, второй 0.
Рисунок 7. Использование семафоров для синхронизации потоков
29.Взаимные блокировки. Условия, необходимые для возникновения тупика.
Тупиковые ситуации надо отличать от простых очередей: хотя те и другие возникают при совместном использовании ресурсов и внешне выглядят похоже: поток приостанавливается и ждет освобождения ресурса. Однако очередь — это нормальное явление, неотъемлемый признак высокого коэффициента использования ресурсов при случайном поступлении запросов. Очередь появляется тогда, когда ресурс недоступен в данный момент, но освободится через некоторое время, позволив потоку продолжить выполнение. Тупик же, что видно из его названия, является неразрешимой ситуацией. Необходимым условием возникновения тупика является потребность потока сразу в нескольких ресурсах.
Процессы требуют предоставления им права монопольного управления ресурсами, которые им предоставляются (условие взаимоисключения);
Процессы удерживают за собой ресурсы, выделенные им, в то же время ожидают выделения дополнительных ресурсов (условие ожидания ресурсов);
Ресурсы нельзя отобрать у процесса, удерживающего их, пока эти ресурсы не будут использованы для завершения работы (условия неперераспределенности);
Существует кольцевая цепь процессов, в которой каждый процесс удерживает за собой один или более ресурсов, требующихся следующему процессу цепи (условие кругового ожидания).
30.Обнаружение взаимоблокировки при наличии одного ресурса каждого типа.
Методы борьбы с блокировками:
Метод страуса. Если мы будем игнорировать проблему, то она возможно не принесет вреда. Применяется, когда потери от взаимоблокировок незначительны. Популярные ОС обычно так и делают.
Обнаружение и исправление после возникновения блокировки (если существуют методы)
Динамическое избежание взаимоблокировок (ОС не допускает их возникновения)
Предотвращение с помощью опровержения первого условия необходимости (не давать ресурсы монопольно)
Обнаружение взаимоблокировки при наличии одного ресурса каждого типа:
Рисунок 8. Система из 7ми процессов и 6ти ресурсов
1)Начальное условие: задаем L - пустой список. Ребра не маркированы
2)Текущий узел добавляем в конец списка L и проверяем количество появлений узла в списке. Если есть повторы, то есть цикл, то алгоритм завершается
3)Для заданного узла смотрим, выходит ли у него хоть 1 немаркированное ребро. Да - переход к 4, нет - переход к 5
4)Случайным образом выбираем немаркированное ребро и отмечаем его. По нему переходим к новому текущему узлу и возвращаемся к 2.
5)Удаляем последний узел из списка и возвращаемся к следующему узлу. Обозначаем его текущим и возвращаемся к 2. Если это первоначальный узел, значит граф не содержит циклов и алгоритм завершится.
31.Обнаружение взаимоблокировок при наличии нескольких ресурсов каждого типа.
В системе имеем наборы однотипный ресурсов (одного класса). Классов ресурсов m. Процессов n. Для обнаружения тупиков поддерживается несколько структур.
E - вектор существующих ресурсов
С - матрица текущего распределения
Элемент Cij - показывает, сколько экземпляров j-го класса ресурсов принадлежит i-му процессу.
R - матрица запросов, показывает, сколько еще экземпляров ресурсов нужно процессу для благополучного завершения (j-го ресурса i-му процессу)
A - вектор доступных ресурсов.
Алгоритм:
1)Ищем немаркированный процесс Pi, для которого i-я строка матрицы R <=A (запросы меньше возможностей)
2)2Если так, процесс найдет, прибавляем i-ю строку матрицы С к вектору А и возвращаемся к 1. Если таких процессов не существует, то алгоритм заканчивается (если все процессы промаркированы, то тупика нет).
32.Предотвращение взаимоблокировки. Алгоритм банкира для одного вида ресурсов.
Говорят, что состояние безопасно, если оно не находится в тупике и существует некоторый порядок планирования, при котором каждому процессу можно работать до завершения даже если все процессы захотят немедленно получить свое максимальное количество ресурсов.
Алгоритм банкира для 1 вида ресурсов (основан на избегании опасных состояний):
Алгоритм рассматривает запросы на предоставления ресурсов по мере их поступления. Каждый раз проверяет, приведет ли удовлетворение запроса к безопасному состоянию. Если да - запрос удовлетворяется, если нет - откладывается на более позднее время.
33.Предотвращение взаимоблокировки. Алгоритм банкира для нескольких видов ресурсов.
Рассмотрим систему:
Вектора: E=(6342) - существующие ресурсы, P=(5322) - занятые ресурсы, A=(1020) - доступные ресурсы.
Рисунок 9. Алгоритм банкира для несколько видов ресурсов
Если состояние безопасное, то ресурс выделить можно, если нет - нельзя. На практике эти алгоритмы сложно реализовать.
34.Синхронизирующие объекты ОС: системные семафоры, мьютексы, события, сигналы, ждущие таймеры.
В случае синхронизации потоков разных процессов операционная система должна предоставлять потокам системные объекты синхронизации, которые были бы видны для всех потоков, даже если они принадлежат разным процессам и работают в разных адресных пространствах. Примерами таких синхронизирующих объектов ОС являются системные семафоры, мьютексы, события, таймеры и другие.
Все синхронизирующие объекты могут находиться в двух состояниях:
сигнальном
несигнальном (свободном).
Мьютексы
Объекты-взаимоисключения (мьютексы, mutex - от MUTual EXclusion) позволяют координировать взаимное исключение доступа к разделяемому ресурсу. Сигнальное состояние объекта (т.е. состояние "установлен") соответствует моменту времени, когда объект не принадлежит ни одному
потоку и его можно "захватить". Предположим, что мьютекс находится в сигнальном состоянии, в этом случае поток тут же становится его владельцем, устанавливая его в несигнальное состояние, и входит в критическую секцию. После того как поток выполнил работу с критическими данными, он «отдает» мьютекс, устанавливая его в сигнальное состояние. Если какой-либо поток ожидает его освобождения, то он становится следующим владельцем этого мьютекса, одновременно мьютекс переходит в несигнальное состояние.
Системные семафоры
Существует еще один метод синхронизации потоков, в котором используются семафорные объекты API. В семафорах применен принцип действия мьютексов, но с добавлением одной существенной детали. В них заложена возможность подсчета ресурсов, что позволяет заранее определенному числу потоков одновременно войти в синхронизуемый участок кода. Для создания семафора используется функция CreateSemaphore.
События
События используются в качестве сигналов о завершении какой-либо операции. В отличие от мьютексов, они не принадлежат ни одному потоку. Объект-событие обычно используется не для доступа к данным, а для того, чтобы оповестить другие потоки о том, что некоторые действия завершены. Пусть, например, в некотором приложении работа организована таким образом, что один поток читает данные из файла в буфер памяти, а другие потоки обрабатывают эти данные, затем первый поток считывает новую порцию данных, а другие потоки снова ее обрабатывают и так далее. В начале работы первый поток устанавливает объект-событие в несигнальное состояние. Все остальные потоки выполнили вызов Wait(X), где X — указатель события, и находятся в приостановленном состоянии, ожидая наступления этого события. Как только буфер заполняется, первый поток сообщает об этом операционной системе, выполняя вызов Set(X). Операционная система просматривает очередь ожидающих потоков и активизирует все потоки, которые ждут этого события.
Ждущие таймеры
Ждущий таймер (waitable timer) представляет собой новый тип объектов синхронизации, поддерживаемый в Windows NT версии 4.0 и выше. Это полноценный объект синхронизации, который может использоваться для организации задержки в одном или нескольких приложениях. Ждущий таймер работает в трех режимах. В режиме «ручного сброса» таймер переходит в установленное состояние при истечении заданной задержки и остается установленным до тех пор, пока функция SetWaitableTimer не задаст новую задержку. В режиме «автоматического сброса» таймер переходит в установленное состояние при истечении заданной задержки и остается установленным до первого успешного вызова функции ожидания. Каждый раз при истечении времени задержки разрешается выполнение лишь одной нити. Наконец, ждущий таймер может выполнять функции интервального таймера, который перезапускается с заданной задержкой после каждого срабатывания объекта.
Главная особенность, отличающая ждущие таймеры от системных, — то, что ждущие таймеры могут совместно использоваться несколькими приложениями. Процессы получают дескрипторы ждущих таймеров так же, как они получают дескрипторы мьютексов: дублированием, наследованием или открытием по имени.
35.Организация обмена данными между процессами (каналы, разделяемая память, почтовые ящики, сокеты).
Операционная система, имея доступ ко всем областям памяти, играет роль посредника в информационном обмене прикладных потоков. При необходимости в обмене данными поток обращается с запросом к ОС. ОС, пользуясь своими привилегиями, создает различные системные средства связи. Многие из средств межпроцессного обмена данными выполняют также и функции синхронизации: в том случае, когда данные для процесса-получателя отсутствуют, последний