Второй алгоритм решения для читателей-писателей - PullRequest
5 голосов
/ 02 апреля 2012

Мне очень трудно разобраться во втором алгоритме проблемы читателей-писателей.Я понимаю общую концепцию, что авторы получат приоритет над читателями (читатели могут голодать).Я даже понимаю условную переменную реализации этого алгоритма Reader / Writer Locks в C ++ .Однако реализация семафора и мьютекса для меня не имеет смысла.Это пример из Википедии:

int readcount, writecount; (initial value = 0)
semaphore mutex 1, mutex 2, mutex 3, w, r ; (initial value = 1)

READER
  P(mutex 3);
    P(r);
      P(mutex 1);
        readcount := readcount + 1;
        if readcount = 1 then P(w);
      V(mutex 1);
    V(r);
  V(mutex 3);

  reading is done

  P(mutex 1);
    readcount := readcount - 1;
    if readcount = 0 then V(w);
  V(mutex 1);


WRITER
    P(mutex 2);
      writecount := writecount + 1;
      if writecount = 1 then P(r);
    V(mutex 2);

  P(w);
    writing is performed
  V(w);

  P(mutex 2);
    writecount := writecount - 1;
    if writecount = 0 then V(r);
  V(mutex 2);

[http://en.wikipedia.org/wiki/Readers-writers_problem][2]

Я не понимаю, для чего три семафора (мьютекс 3, r и мьютекс 1) предназначены для блокировки чтения.Разве одного семафора недостаточно для считывания?

Ответы [ 2 ]

10 голосов
/ 02 апреля 2012

mutex 1 защищает переменную readcount;mutext 2 защищает writecount переменная;mutex r защищает операции чтения, а mutext w защищает операции записи.

1) Предположим, что пишущий вводит:

Сигналы mutex 2 и увеличивает writercount к учетной записидля дополнительного записывающего (самого себя) Поскольку это единственный процесс, который может изменить writercount (поскольку он содержит mutex 2), он может безопасно проверить, является ли он единственным записывающим устройством (writercount==1), если true, он сигнализируетмьютекс r для защиты читателей от проникновения - другие авторы (writercount > 1) могут наслаждаться мьютексом r, уже сигнализируемым.

Затем автор сообщает мьютексу w, чтобы защитить его изменения от других(одновременные) писатели.

Последний писатель (writecount==1) выпускает мьютекс r, чтобы позволить читателям выполнять свои задачи.

2) Предположим, что читатель входит:

Сигналы mutex 3 для защиты логики настройки считывателей от других считывателей;затем сигнализирует мьютекс r для защиты от других авторов (помните, что r сигнализируется во время работы авторов);затем сигнализирует mutex 1 о защите счетчика чтения (от других читателей, которые могут выходить из него) и, если это первый считыватель (readercount == 1), сигнализирует мьютекс w о защите от писателей (теперь исключает писателей из выполнения их операций).

Чтение может выполняться параллельно, поэтому не требуется никакой защиты от других читателей во время чтения (помните, мьютекс w удерживается на этом этапе, поэтому нет вмешательства со стороны писателей)

Тогда последнийчитатель сбрасывает мьютекс записи (w), чтобы разрешить писателям.


Хитрость, которая предотвращает голодание писателя, заключается в том, что писатели изображают из себя читателей (при сигнале мьютекса p), поэтому у них есть хороший шанспланировать, даже когда есть много читателей.Кроме того, mutex 3 не позволяет слишком большому количеству читателей ожидать мьютекс r, поэтому у писателей есть хорошие шансы сообщить r, когда они придут.

4 голосов
/ 02 апреля 2012

Взгляните на Параллельное управление с помощью «Readers» и «Writers» от P.J. Courtois, F. Heymans и D.L. Парнас , который является ссылкой для кода в Википедии. Это объясняет, почему нужны все мьютексы.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...