Seconda soluzione algoritmo a Lettore-scrittore

Question

Sto attraversando un periodo difficile per capire il secondo algoritmo del problema dei lettori-scrittori. Capisco il concetto generale, che gli scrittori avranno la priorità sui lettori (i lettori possono morire di fame). Capisco persino l'implementazione della variabile condizionale di questo algoritmo Reader/Writer Locks in C++. Tuttavia, l'implementazione mutex del semaforo & non ha senso per me. Questo è un esempio da 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] 

Non capisco quello che i tre semafori (mutex 3, R, e mutex 1) sono per nella serratura lettore. Non è sufficiente un semaforo per il conto?

Answer 1

Dai uno sguardo allo Concurrent Control with "Readers" and "Writers" by P.J. Courtois, F. Heymans, and D.L. Parnas, che è il riferimento per il codice su Wikipedia. Spiega perché sono necessari tutti i mutex.

Answer 2

mutex 1 protegge la variabile readcount; mutext 2 protegge writecount variabile; mutex r protegge le operazioni di lettura e il mutext w protegge le operazioni di scrittura.

1) Supponiamo uno scrittore è disponibile in:

Segnali mutex 2 e incrementi writercount per tenere conto per lo scrittore extra (se stesso) Dal momento che è l'unico processo che può cambiare writercount (come è in possesso di mutex 2), può tranquillamente verificare se è l'unico writer (writercount==1), se è vero, segnala mutex r per proteggere i lettori dall'arrivo - altri writer (writercount > 1) possono godere del mutex r segnalato già.

Lo scrittore quindi segnala mutex w per proteggere le sue modifiche da altri scrittori (concorrenti).

Ultimo scrittore (writecount==1) rilascia mutex r per consentire ai lettori di eseguire i propri compiti.

2) Supponiamo un lettore è disponibile in:

Segnali mutex 3 per proteggere la logica di impostazione dei lettori da altri lettori; quindi segnala mutex r per proteggere da altri autori (ricordare, r viene segnalato mentre gli scrittori sono operativi); quindi segnala mutex 1 per proteggere il conteggio (da altri lettori che potrebbero essere usciti) e se è il primo lettore (readercount == 1), i segnali mutex w per proteggere dagli scrittori (ora esclude gli scrittori dall'esecuzione delle loro operazioni).

La lettura può essere fatto in parallelo, in modo da nessuna protezione è necessaria da altri lettori durante la lettura (ricordate, mutex w si terrà, a questo punto, in modo che nessun intereference da scrittori)

Poi l'ultimo lettore di reimposta il mutex scrittura (w) per consentire agli scrittori.

---

Il trucco che impedisce scrittore inedia è che gli scrittori pongono come i lettori (quando segnalazione mutex p), in modo da avere una buona possibilità di ottenere stabilito, anche se ci sono molti lettori. Inoltre, mutex 3 impedisce a troppi lettori di attendere il mutex r, in modo che gli autori abbiano buone probabilità di segnalare r quando arrivano.