2010-01-31 10 views
20

sto scrivendo un programma in cui v'è un oggetto condiviso da più thread:Devo bloccare l'oggetto durante la lettura?

  • A) Più thread di scrittura scrivono all'oggetto (tutto esegue la stessa funzione )
  • B) Un filo di lettura che accede l'oggetto ogni 5 secondi
  • C) un filo che accede all'oggetto c'è una richiesta dell'utente leggere

ovviamente è necessario bloccare l'oggetto durante la scrittura, come non vogliamo più thread a w rito all'oggetto allo stesso tempo.

Le mie domande sono:

  1. E 'anche necessario bloccare l'oggetto durante la lettura da esso?
  2. Ho ragione di pensare che se si blocca l'oggetto solo quando si scrive, una sezione critica è sufficiente; ma se blocciamo l'oggetto durante la lettura o la scrittura, è necessario un mutex?

Sto ponendo questa domanda perché in Microsoft Office non è possibile che due istanze di Word accedano a un documento in modalità di accesso in lettura/scrittura; ma mentre il documento viene aperto in modalità lettura/scrittura, è possibile aprire un'altra istanza di Word per accedere al documento in modalità di sola lettura. La stessa logica si applicherebbe al threading?

+2

È utile osservare come i database relazionali fanno ciò, sono i padroni dell'accesso ai dati condivisi. – skaffman

risposta

11

Come Ofir già scritto - se si cerca di leggere i dati da un oggetto che qualche altro thread sta cui intervenire - si potrebbe ottenere i dati in uno stato incoerente.

Ma se sei sicuro che l'oggetto non viene modificato, puoi ovviamente leggerlo da più thread. In generale, la domanda che si pone è più o meno il problema dei lettori - vedi http://en.wikipedia.org/wiki/Readers-writers_problem

Infine, una sezione critica è un termine astratto e può essere implementata utilizzando un mutex o un monitor. Lo zucchero di sintassi per una sezione critica in java o C# (sincronizzato, blocco) utilizza un monitor sotto le copertine.

4

È necessario, perché altrimenti (a meno che le operazioni non siano atomiche) si può leggere uno stato intermedio.

Si consiglia di consentire più lettori allo stesso tempo che richiede un tipo (bit) più complesso di blocco.

+0

L'operazione di scrittura è atomica, ma grazie mille per la risposta. – Andy

3

È anche necessario bloccare l'oggetto durante la lettura da esso?

Se qualcos'altro potrebbe scriverlo allo stesso tempo - sì. Se solo si potesse verificare un'altra lettura - no. Nelle tue circostanze, direi: sì.

Sono corretto nel pensare che se si blocca l'oggetto solo durante la scrittura, è sufficiente una sezione critica ; ma se abbiamo bloccare l'oggetto durante la lettura o la scrittura , è necessario un mutex?

No, è possibile utilizzare una sezione critica per entrambi, a parità di altre condizioni. I mutex hanno aggiunto funzionalità su sezioni (i mutex denominati possono essere utilizzati da più processi, ad esempio), ma non penso che tu abbia bisogno di queste caratteristiche qui.

+0

Grazie. Ora mi rendo conto che le sezioni critiche possono essere utilizzate per diverse subroutine, purché le subroutine appartengano allo stesso processo. – Andy

1
  1. dipende da come lo si utilizza e lo si legge. se la tua lettura è atomica (cioè, non verrà interrotta da scrittura) e il thread letto non ha dipendenza con i thread di scrittura, allora forse potresti saltare il blocco di lettura. Ma se l'operazione di "lettura" richiede un po 'di tempo e richiede l'interposizione di oggetti pesanti, è necessario bloccarla per la lettura.

  2. se la lettura non richiede molto tempo (ad esempio, non ritarderà troppo i thread di scrittura), la sezione critica dovrebbe essere sufficiente.

0

Il blocco è necessario solo quando due processi possono modificare gli stessi elementi della tabella del database. quando vuoi leggere i dati è sempre sicuro. leggi i dati di un database coerente. il processo che modifica i dati ha una versione shadow che è coerente e sovrascrive i dati correnti quando li salvi. ma se si sta eseguendo un processo di lettura che dipende dal valore critico degli elementi del database, è necessario cercare i blocchi che indicano che è probabile che questi valori vengano alterati. quindi la tua lettura è in ritardo fino a quando il blocco non è andato.

Problemi correlati