Blocco condiviso ed esclusivo

Question

Blocco condiviso ed esclusivo

#1 da (2 voti)
#2 da (0 voti)

2

Ho bisogno di un "blocco" che può essere condiviso o tenuto in esclusiva, che fornirà il seguente comportamento per la seguente sequenza di eventi:

Processo A: Richieste e viene concesso un blocco condiviso
Processo B: richiede un blocco esclusivo ed è bloccato dalla proprietà di A del blocco
Processo C: richiede un blocco condiviso ed è bloccato perché B è in linea per un blocco esclusivo

Avevo pensato che Unix flock avrebbe fornito queste semantiche, ma poi scoperto che nel passaggio 3, la richiesta di Process C per un blocco condiviso avrebbe avuto successo e la richiesta di Process B per un blocco esclusivo sarebbe concesso solo quando non ci fossero serrature condivise. Questo ha lo sfortunato (per me) effetto che, più processi concorrenti ci richiedono blocchi condivisi, più lungo un processo che richiede un blocco esclusivo dovrà attendere una finestra in cui non sono presenti blocchi in sospeso.

Il comportamento che cerco, in altre parole, è che, dal momento in cui un processo richiede un blocco esclusivo, nel tempo in cui viene concesso il blocco e fino al momento in cui rilascia il blocco blocco, tutte le successive richieste di blocco condiviso verranno accodate e bloccate.

Quale tipo di blocco ha le proprietà di cui ho bisogno?

locks queueing

posta Chap 19.12.2014 - 18:37

fonte

2 risposte

Leggi altre domande sui tag locks queueing

Metodo / modello di sviluppo del software adatto per progetti di R & S Restituzione dell'oggetto / $ questo [duplicato]

score 2 · Answer 1

Hai bisogno di un blocco di lettura-scrittura che darà la priorità ai suoi blocchi di scrittura. A è possibile impostare un rwlock di posix per preferire lo scrittore durante la sua inizializzazione.

O come detto nella pagina wiki collegata:

Write-preferring RW locks avoid the problem of writer starvation by preventing any new readers from acquiring the lock if there is a writer queued and waiting for the lock. The writer will then acquire the lock as soon as all readers which were already holding the lock have completed. The downside is that write-preferring locks allows for less concurrency in the presence of writer threads, compared to read-preferring RW locks. Also the lock is less performant because each operation, taking or releasing the lock for either read or write, is more complex, internally requiring taking and releasing two mutexes instead of one. This variation is sometimes also known as "write-biased" readers-writer lock.

score 0 · Answer 2

Tutto ciò che serve per costruire strutture di blocco arbitrarie è un mutex e una variabile di stato. Nel contesto del filesystem, un mutex consiste in open("/tmp/foo.lock", O_WRONLY|O_TRUNC|O_CREAT|O_EXCL) da acquisire (seguito da una chiamata a close() ) e remove("/tmp/foo.lock") da rilasciare. Per bloccare il mutex, usa inotify o (se sai che non rimarrà bloccato o soffrirà di pesanti conflitti) occupato- aspettalo La variabile di stato può essere un file secondario in /tmp (o altrove, se riesci a vivere con la pulitura manuale dei file obsoleti dopo il crash del programma). Il resto dovrebbe essere abbastanza semplice da progettare.