Подготовка квалификационного экзамена (серия 7 деталей)
Если вы следили за ним, я в настоящее время учусь на квалификационном экзамене PhD. В рамках этого экзамена мне нужно немного освежить свои знания операционных систем. Ранее я освещал несколько механизмов синхронизации процессов, и теперь я хочу начать копаться в том, как эти механизмы можно использовать для решения реальных проблем, таких как проблема читателей.
Обзор проблем с читателями читателей
В одном из распространенных проблем – это уравновешивание, которая имеет доступ к общей переменной. В частности, какие правила мы должны установить доступ к общему доступу к памяти, чтобы действия были безопасны, но также и эффективны?
В частности, проблема с читателями читателей фокусируется на проблемах, связанных с балансировкой потоков или процессов, которые либо хотят прочитать из общего явления памяти, либо написать. Другими словами, как мы можем планировать темы, чтобы получить желаемый результат (т.е. приоритет читателей, приоритет авторов и т. Д.)?
В этой статье мы рассмотрим несколько сценариев читателей и попытаемся решить их, используя некоторые из механизмов, о которых мы болтали в прошлый раз, как семафоры и мониторы. Чтобы быть ясным, весь код в этой статье будет псевдокодом, похожим на питон, за исключением потенциальных примеров, использующих функции параллелизма Java. Все примеры заимствованы из лекционных примечаний CSE 6431 Университета штата Огайо:
- OSU CSE 6431 Синхронизация процесса ЧАСТЬ 2 (Семафоры)
- OSU CSE 6431 Синхронизация процесса Часть 3 (Семафоры)
- OSU CSE 6431 Синхронизация процесса Часть 4 (Мониторы)
Естественно, весь анализ мой собственный.
Проблемные решения читателей
В этом разделе мы рассмотрим различные решения задачи читателей с использованием различных механизмов синхронизации процессов. Каждый подраздел содержит различный тип раствора, который впоследствии организован в подразделах с помощью механизма.
Серийное решение
Орчест, чтобы несколько читателей и писателей могут быть сложными. Один из способов решить эту проблему – организовать чтения и записать, что только один процесс может получить доступ к общей памяти за раз. С этим решением правильно достичь правильности. Однако эффективность не гарантируется, поскольку нет механизма для приоритета процесса.
Семафоры
С помощью семафоров мы можем определить две процедуры: читатель и писатель. Каждая процедура защищена одним и тем же мутекс:
procedure reader(): P(mutex)V(mutex) procedure writer(): P(mutex) V(mutex)
Мониторы
С мониторами общий ресурс может быть определен внутри монитора. Затем мы настроем две процедуры: читатель и писатель. Поскольку ресурсы монитора защищены, мы можем случайно вызвать процедуры, не беспокоясь о каких -либо условиях гонки:
procedure reader():procedure writer():
В общем, это сделает работу, но это не идеально.
Одновременное решение читателя
Поскольку операции чтения не влияют на общий ресурс, мы обычно позволяем им происходить одновременно. Другими словами, если два читателя приходят, когда ничего не пишут в наш общий ресурс, мы должны позволить обоим читателям прочитать.
Семафоры
С семафорами процесс чтения должен быть разбит на три этапа:
- Проверьте, безопасно ли это для чтения (то есть писатели в настоящее время не пишут)
- Читать
- Проверьте, безопасно ли писать (то есть больше нет читателей)
Кроме того, мы должны представить дополнительный мутекс, чтобы мы могли начать отслеживать читателей в одной очереди и писателей в другой очереди. Кроме того, мы также должны представить общую переменную, которую мы будем использовать для отслеживания количества активных читателей:
procedure reader():
# Stage 1
P(reader_mutex)
if readers = 0:
P(writer_mutex)
readers++
V(reader_mutex)
# Stage 2
# Stage 3
P(reader_mutex)
readers--
if readers = 0:
V(writer_mutex)
V(reader_mutex)
procedure writer():
P(writer_mutex)
V(writer_mutex)
Обратите внимание, как Читатели Переменная используется для проведения связи между читателями и писателями. Если читатель понимает, что это первое, он должен зацепить писателя Mutex, чтобы избежать каких -либо проблем доступа к памяти. В случае успеха читатели держат этот мутекс, пока не останется читателей.
Если по какой -то причине первый читатель не получает писателя Mutex, он застрял в ожидании, а также удерживает читателя Mutex. Другими словами, все читатели заморожены, пока первый читатель не получит писателя Mutex.
Мониторы
Как и Semaphores, решение для мониторов для одновременного доступа к считыванию требует нескольких изменений. В частности, нам нужно будет разделить процедуру читателя на две процедуры. Таким образом, мы можем удалить функциональность считывания с монитора, поэтому чтения не встречаются последовательно. Кроме того, нам нужно определить переменную общих читателей, как и раньше.
Тем не менее, существует небольшая разница в решении монитора. Вместо того, чтобы поддерживать две очереди явно, мы поддерживаем одну, используя переменную условия, называемая автором:
procedure begin_read():
readers++
# Reading occurs between these procedures
procedure end_read():
readers--
if readers = 0:
writer.signal
procedure write():
if readers > 0:
writer.wait
writer.signal
Поскольку только один процесс может выполнять процедуру монитора за раз, нам не нужно беспокоиться о каких -либо условиях гонки в этом отношении. Однако, поскольку общий ресурс (то есть файл) не защищен нашим монитором, мы должны предотвратить писатели во время одновременных чтений. Для этого мы представляем переменную условия писателя, которую мы используем, чтобы заполучить писателей, если есть какие -либо читатели.
В противном случае жизнь довольно проста для читателя. Если мы можем читать (то есть не заблокированы монитором), мы увеличиваем количество читателей перед чтением. После прочтения мы уменьшаем количество читателей. Если нынешний читатель является последним читателем, он управляет любыми авторами ожидающих.
Приоритетное решение читателей
По сути, решение для одновременного считывателя работает, уделяя приоритет тому, какой процесс прибывает в первую очередь. В некоторой степени читатели получают приоритет. В конце концов, пока есть читатели, они будут продолжать читать. Тем не менее, писатели никогда не передают контроль читателям, поэтому возможно, что писатели могут некоторое время голодать читателей (и наоборот).
Если мы хотим приоритетное решение истинного читателей, мы должны изучить механизм, в котором авторы передают контроль читателям, когда они закончат.
Семафоры
Чтобы создать приоритетное решение читателей с помощью семафоров, мы должны представить еще один семафор:
procedure reader():
# Stage 1
P(reader_mutex)
if readers = 0:
P(writer_mutex)
readers++
V(reader_mutex)
# Stage 2
# Stage 3
P(reader_mutex)
readers--
if readers = 0:
V(writer_mutex)
V(reader_mutex)
procedure writer():
P(sync_mutex)
P(writer_mutex)
V(writer_mutex)
V(sync_mutex)
На первый взгляд, это решение выглядит точно так же, как решение о параллельных читателях. Конечно, разница в процедуре писателя, которая использует новый мутекс. Как могут две дополнительные строки гарантировать приоритет читателей?
Оказывается, новый Mutex теперь гарантирует, что процессы писателей только когда -либо внедрены для writer_mutex Когда у них уже есть sync_mutex Анкет Другими словами, может быть только один писатель, ожидающий writer_mutex вовремя. В результате у автора нет возможности передать контроль другому писателю, если читатель ждет writer_mutex Анкет
Мониторы
К сожалению, решение монитора не так элегантно, как решение для семафора. Вдобавок к добавлению новой переменной условия и новой общей переменной, решение монитора должно разбить процедуру автора:
procedure begin_read():
if writing:
safe_read.wait
readers++
safe_read.signal
procedure end_read():
readers--
if readers = 0:
safe_write.signal
procedure begin_write():
if writing or readers > 0:
safe_write.wait
writing = true
procedure end_write():
writing = false
if safe_read.queue:
safe_read.signal
else:
safe_write.signal
В отличие от предыдущего решения монитора, это решение зависит от доступа к вождению через сигнализацию в очереди. В частности, мы поддерживаем две переменные условия: Safe_read и safe_write Анкет Если это безопасно читать, мы сигнализируем Safe_read очередь. Между тем, если писать безопасно, мы сигнализируем safe_write очередь.
С точки зрения чтения, мало что изменилось. Если есть какое -либо активное письмо, читатели должны ждать. В противном случае они читают. Когда читатели закончат чтение, они должны уменьшить количество читателей. Как и в соответствии с решением одноразовых считывателей, последний читатель отвечает за сигнализацию следующего автора.
С точки зрения письма, многое изменилось. В дополнение к новой общей переменной под названием Написание , теперь у нас есть две процедуры вместо одной: begin_write и end_write Анкет
begin_write Процедура отвечает за проверку того, что ее можно безопасно писать (то есть никто больше не читает, и нет читателей). Если писать небезопасно, писатели должны ждать. В противном случае они указывают, что они пишут перед написанием.
Между тем, end_write Процедура указывает на то, что письмо завершено. Если есть какие -либо читатели, писатели несут ответственность за их сигнал (он же приоритет читателей). В противном случае они сигнализируют другого писателя.
Для меня, хотя это более сложное, это решение кажется намного более интуитивно понятным, чем раствор для семафора. В частности, у нас есть прямая связь между процессами, которые больше похоже на то, как мы выполняем такую задачу в нашей повседневной жизни.
Связанные проблемы
В этой статье мы сосредоточились на двух механизмах синхронизации процессов, семафоры и мониторов, а также на том, как их можно использовать для решения нескольких версий задачи читателей. В дополнение к проблемам, рассматриваемым в этой статье, есть несколько связанных проблем, включая:
- Приоритет писателей
- Сначала наименьшая работа
- Чередование читателей и писателей
- Ограничение одновременных читателей
И я уверен, что есть еще много. В интересах времени я решил не решать эти проблемы. Однако, если вам интересно узнать больше об этих темах, я был бы рад расширить этот список.
Хотите узнать больше?
На данный момент я сейчас по три темы, которые мне нужно изучить для этого квалификационного экзамена. На данный момент я буду продолжать проходить через операционные системы. Однако в какой -то момент мне действительно нужно будет заниматься алгоритмами.
А пока вы можете помочь мне вырастить этот сайт по Стать участником Анкет Участники автоматически добавляются в Список рассылки и они получают доступ к дополнительному контенту, такому как Статьи в блоге Анкет
Точно так же вы всегда можете просмотреть некоторые из моих любимых статей на этом сайте:
- Разница между заявлениями и выражениями
- Как преподавать массивы в информатике
- Работа со сложными студентами колледжа
Как всегда, спасибо, что заглянули!
Пост Решения для проблем с читателями появился первым на Renegade Coder Анкет
Подготовка квалификационного экзамена (серия 7 деталей)
Оригинал: “https://dev.to/renegadecoder94/solutions-to-the-readers-writers-problem-1147”