2013-03-10 7 views
7

Ho una domanda riguardante le barriere di memoria quando si utilizza un Condition fornito da un Lock.Barriere di memoria e java.util.concurrent.locks.Esempio di configurazione

Per quanto riguarda l'esempio fornito in the javadoc for Condition, ho una domanda circa l'uso di:

int putptr, takeptr, count; 

Non dovrebbe questi attributi essere dichiarato volatili? Come ho capito dall'esempio, un thread potrebbe non vedere le modifiche di, ad esempio, count.

Oppure, quando viene chiamato signal(), tutte le modifiche apportate dal momento dell'acquisizione del blocco sono visibili ad altri thread? Molto simile ad un codice in un blocco synchronized?

In caso affermativo, le modifiche sono visibili quando viene chiamato signal() oppure quando viene chiamato il blocco unlock()?

Grazie.

Edit: vedo nel javadoc di Lock: implementazioni

Tutto blocco devono far rispettare la stessa semantica di sincronizzazione della memoria, come previsto dalla funzione built-in blocco del monitor, come descritto nel paragrafo 17.4 di The Java ™ Lingua Specifica:

  • Un'operazione di blocco riuscita ha gli stessi effetti di sincronizzazione della memoria di un'azione di blocco riuscita.
  • Un'operazione di sblocco riuscita ha gli stessi effetti di sincronizzazione della memoria di un'azione di sblocco completata.

Operazioni di blocco e sblocco non riuscite e operazioni di blocco/sblocco di rientro, non richiedono alcun effetto di sincronizzazione della memoria.

significano: "Un'operazione serratura successo ha gli stessi effetti di sincronizzazione memoria come entrare in un blocco synchronized", e "Un'operazione sblocco successo ha gli stessi effetti di sincronizzazione memoria come uscire dal blocco synchronized"?

+0

l'effetto è lo stesso di 'synchronized' e' Object.wait(), Object.notify() ' – irreputable

+0

' await() 'si sblocca quando si entra e si blocca all'uscita. – irreputable

risposta

7

Il modo in cui è necessario leggerlo è, tutte le scritture che si verificano prima di un lock.unlock sono visibili a tutti i successivi lock.lock. Un thread che è await ing, quando svegliato, essenzialmente farà lock.lock. Quindi tutte le scritture che si sono verificate dopo lo sblocco precedente saranno ora visibili.

Il signal non ha semantica di memoria, come indica il punto successivo or when unlock() is called on the lock è corretto.

significano: "Un'operazione serratura successo ha gli stessi memoria effetti di sincronizzazione come entrare in un blocco sincronizzato", e "A dell'operazione di sblocco successo ha la stessa sincronizzazione memoria effetti come uscire dal blocco sincronizzato"?

Sì, esattamente! Più specificamente il compilatore invierà istruzioni per codice byte monitorenter e monitorexit.

+1

Ok, grazie. Potresti anche controllare la mia modifica? – FBB

+0

Grazie per la risposta completa. – FBB

Problemi correlati