Solución del Segundo Algoritmo para Lectores-Escritor

Question

Me está resultando muy difícil entender el Segundo Algoritmo para el problema Lectores-Escritores. Entiendo el concepto general, que los escritores tendrán prioridad sobre los lectores (los lectores pueden morir de hambre). Incluso entiendo la implementación de la variable condicional de este algoritmo Reader/Writer Locks in C++. Sin embargo, la implementación de mutex del semáforo & no tiene sentido para mí. Este es un ejemplo de Wikipedia:

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] 

No entiendo lo que los tres semáforos (mutex 3, r, y mutex 1) están en la cerradura lector. ¿No hay un semáforo suficiente para la cuenta de lectura?

Answer 1

Eche un vistazo a Concurrent Control with "Readers" and "Writers" by P.J. Courtois, F. Heymans, and D.L. Parnas, que es la referencia del código en Wikipedia. Explica por qué son necesarios todos los mutex.

Answer 2

mutex 1 protege la variable readcount; mutext 2 protege writecount variable; mutex r protege las operaciones de lectura y el texto muteto w protege las operaciones de escritura.

1) Supongamos que un escritor entra en juego:

señales mutex 2 e incrementa writercount para tener en cuenta el escritor adicional (sí) Puesto que es el único proceso que puede cambiar writercount (ya que es la celebración de mutex 2), puede comprobar de forma segura si es el único escritor (writercount==1); si es verdadero, indica mutex r para evitar que los lectores entren; otros escritores (writercount > 1) pueden disfrutar del mutex r que ya se ha señalado.

El escritor señala el mutex w para proteger sus cambios de otros escritores (concurrentes).

Último autor (writecount==1) libera mutex r para permitir que los lectores realicen sus tareas.

2) Supongamos que un lector entra en juego:

señales mutex 3 para proteger la lógica de configuración de los lectores de otros lectores; a continuación, indica mutex r para proteger de otros escritores (recuerde, r se señala mientras los escritores están en funcionamiento); luego señala mutex 1 para proteger la cuenta leída (de otros lectores que podrían estar saliendo) y si es el primer lector (readercount == 1), indica mutex w para proteger de los escritores (ahora excluye a los escritores de realizar sus operaciones).

La lectura puede hacerse en paralelo, por lo que no se necesita protección de otros lectores al leer (recuerda, mutex w se encuentra detenido en este punto, por lo que no intereference de escritores)

Entonces el último lector restablece el mutex de escritura (w) para permitir escritores.

---

El truco que evita el hambre escritor es que los escritores se hacen pasar por los lectores (cuando señalización mutex p), por lo que tienen una buena oportunidad de conseguir programadas incluso cuando hay muchos lectores. Además, mutex 3 impide que muchos lectores esperen en mutex r, por lo que los escritores tienen una buena oportunidad de señalar r cuando lleguen.