СПО (Корнилов) / Лекции / вар2 / Операционные системы (Корнилов)

Вопросы:

•Важен ли порядок P операций?

•Важен ли порядок V операций?

•Нужны ли изменения для 2 производителей и 2 потребителей?

Реализация семафоров для многопроцессорных машин

Счетчик событий

Аналогичен семафорам, реализуется на основе следующих примитивов:

Лекция 7: Мониторы и условные переменные

9Монитор и условные переменные

9Задача о производителе и потребителе

Монитор и переменные условия

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

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

Первоначально (Хоар, Бринч Хансен) определяли монитор как конструкцию в языке программирования, при этом lock/unlock подставлялись в ходе компиляции соответственно в начале и на выходе из функций монитора. Во многих ОС OS/2, Windows NT, Solaris мониторы строятся на основе явного вызова примитивов взаимного.

Рассмотрим пример взаимодействия двух процессов – передача (прием) данных через кольцевой буфер.

class Buffer { int buf[N]; int head, tail public:

Buffer() { head = tail = 0; } void Put(int value);

void Get(int& value); };

void Buffer::Put(int value)

{

while( (tail+1)%N == head); // пока буфер полон - ждать

// или while( (tail+1)%N == head) Sleep(1); buf[tail] = value; // Разместить данные в буфере tail = (tail+1)%N;

}

void Buffer::Get(int& value)

{

while( tail == head); // пока буфер пуст - ждать

// или while( tail == head) Sleep(1);

value = buf[head]; // Взять данные из буфера head = (head +1)%N;

}

Приведенное решение справедливо только для двух процессов: один передает данные, а другой принимает. Процессы используют разные функции и модифицируют разные переменные: один – head, а другой – tail. Если допускается существование нескольких передающих или нескольких читающих процессов, то операции чтения и записи должны быть защищены критической секцией. В определение класса необходимо добавить переменную MUTEX lock, а в начало и в конец функций Put и Get добавить соответственно захват (lock.Acquire()) и освобождение (lock.Release()) критической секции.

Однако, это решение не верно. Проблема в том, что ожидание внутри критической секции в данном случае приводит к блокировке. Например, если буфер пуст, то мы ждем в цикле while внутри критической секции и другой процесс не сможет выполнить функцию Put, поскольку критическая секция занята.

Для реализации ожидания в мониторах определены специальные переменные (переменныя условия – condition variables), с каждой связана очередь нитей ожидающих событие вне критической секции.

Для переменных условия определены функции: wait(suspend), signal(resume), broadcast.

• wait выход из критической секции, ожидание, возврат в критическую секцию

•signal будит одного ожидающего, если кто-то ждет

•broadcast будит всех ожидающих, если кто-то ждет

Получаем следующее решение: class Buffer {

MUTEX lock

CONDITION full,empty; int buf[N];

int head, tail public:

Buffer() { head = tail = 0; } void Put(int value);

void Get(int& value); };

void Buffer::Put(int value)

{

lock.Acquire();

while( (tail+1)%N == head) full.wait(lock); // ждать buf[tail] = value; // Разместить данные в буфере tail = (tail+1)%N;

empty.signal();

lock.Release();

}

void Buffer::Get(int& value)

{

lock.Acquire();

while( tail == head) empty.wait(lock); // ждать value = buf[head]; // Взять данные из буфера head = (head +1)%N;

full.signal();

lock.Release();

}

Два стиля мониторов: Mesa vs. Hoar

Различие в том, как осуществляется возврат в критическую секцию после wait.

•MESA (реально применяется): после signal не происходит принудительного переключения контекста, разбуженный просто ставится в очередь готовых и должен вновь проверять право на вход в монитор!

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

9Рассмотренный пример справедлив для обоих стилей. Если заменить while на if, то решение останется справедливым для монитора Хоара, но не будет работать для монитора стиля MESA.

9wait и signal не эквивалентны семафорным примитивам - нет счетчика, поэтому signal, выполненный раньше wait эквивалентен пустому оператору.

Сравнение семафоров и мониторов

Попробуем создать на основе семафоров все необходимые для мониторов конструкции. Во-первых с помощью семафора легко создается lock.

Как насчет такого?

Wait() { semaphore->P(); }

Signal() { semaphore->V(); }

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

Уточним.

Wait(Lock *lock) {

lock->Release();

semaphore->P();

lock->Acquire();

}

Signal() { semaphore->V(); }

Переменные условий не имеют памяти, поэтому signal , когда никто не ждет эквивалентен пустому оператору. Последующий wait приведет к ожиданию. С семафорами это не так.

Можно ли решить проблему таким образом?

Signal() {

if(очередь семафора не пуста)

semaphore->V();

}

Нет. Во-первых не корректно смотреть на очередь семафора. Во-вторых, если остановиться в wait после освобождения lock , но до P операции, то сигнал не сработает.

В принципе проблема решается. Это для самостоятельного решения.

Поддержка синхронизации в языках программирования

Проблема в том, что программист должен расставить lock в начале функции монитора и release в каждой точке выхода.

C

Поддержки нет необходимо отследить все выходы из функций монитора.

C++

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

Java

Имеет явную поддержку для нитей и синхронизации.

class Shared { private int value;

public Shared(int initial){ value = initial;} public synchronized int get() { return value; }

public synchronized void add(int incr) { value += incr; }

}

Мораль: нити очень удобны, но не бесплатны

Лекция 8. Типовые задачи синхронизации. Примитивы синхронизации в

Win32 API

9Типовые задачи синхронизации

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

9Атомарные операции

9Объекты ядра Win32 API

Типовые задачи синхронизации

Задача о производителе и потребителе

Моделирует взаимодействие (обмен данными) между двумя процессами: один пишет в буфер, а другой читает из буфера.

Ограничения:

•«Производитель» должен ждать, если буфер полон.

•«Потребитель» должен ждать, если буфер пуст.

•Запись и чтение из буфера – критическая секция.

Задача о читателях и писателях

Моделирует обращение процессов к базе данных. «Читатели» не модифицирую базу данных и могут читать одновременно, если никто не пишет. «Писатель» модифицирует базу данных и может это делать только если никто не пишет и никто не читает.

Ограничения:

•«Читатель» должен ждать, пока кто-то пишет.

•«Писатель» должен ждать, пока кто-то пишет или кто-то читает.

•Модификация переменных состояния (счетчик читающих и т.п.) должно выполняться в критической секции.

Задача о Читателях и Писателях

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

•Читатели никогда не модифицирую базу данных

•Писатели читают и модифицируют базу данных Правила игры таковы:

•Читатели могут работать параллельно, если никто из писателей не модифицирует базу данных

•Модифицировать базу может только один писатель и когда никто не читает из базы данных

•Переменные состояния может просматривать и менять только один процесс

Схема решения

Читатель:

Ждать пока закончит работу писатель (если кто-то пишет) Читать из базы данных При необходимости разбудить ожидающего писателя

Писатель:

Ждать пока закончат работу все читатели (если кто-то читает) Модифицировать базу данных При необходимости разбудить ожидающих читателей

Переменные состояния:

AR – число активных (читающих из БД в данное время) читателей AW – число активных писателей

WR – число ждущих читателей

WW – число ждущих писателей Условные переменные:

ok_to_read – NULL ok_to_write – NULL lock - free

Решение

Reader() {

lock.Acquire();

while((AW+WW)>0) {

WR++; ok_to_read->Wait(&lock); WR--;

}

AR++;

lock.Release();

//====================== ACCESS DB //====================== lock.Acquire();

AR--;

if( AR==0 && WW>0) ok_to_write->Signal(&lock);

lock.Release();

}