2013-03-10 9 views
7

Mam pytanie dotyczące barier pamięci podczas korzystania z Condition dostarczonych przez Lock.Bariera pamięci i przykład java.util.concurrent.locks.Condition

Jeśli chodzi o przykład przewidzianej w the javadoc for Condition, mam pytanie odnośnie stosowania:

int putptr, takeptr, count; 

nie powinno być uznane te atrybuty lotny? Jak rozumiem to na podstawie przykładu, wątek może nie widzieć modyfikacji, np. count.

A może po wywołaniu signal() wszystkie modyfikacje dokonane od momentu pozyskania blokady są widoczne dla innych wątków? Podobnie jak niektóre kod w bloku synchronized?

Jeśli tak, czy zmiany są widoczne po wywołaniu signal() lub po wywołaniu unlock() na zamku?

Dzięki.

Edycja: Widzę w javadoc z Lock: implementacje

Wszystko LOCK musi egzekwować te same semantykę synchronizacji pamięci przewidziane przez wbudowaną blokadą monitora, jak opisano w punkcie 17.4 z Java ™ Języka Specyfikacja:

  • Skuteczna operacja blokowania ma takie same efekty synchronizacji pamięci, co pomyślne działanie blokady.
  • Udana operacja odblokowania ma takie same efekty synchronizacji pamięci, co pomyślne działanie odblokowujące.

Nieudane operacje blokowania i odblokowywania oraz operacje blokowania/odblokowywania wielokrotnego, nie wymagają efektów synchronizacji pamięci.

one oznaczają: „Udana operacja zamek ma takie same skutki jak wprowadzenie synchronizacji pamięci blok synchronized” i „Udana operacja odblokowania ma takie same skutki jak synchronizacji pamięci wyjściu bloku synchronized”?

+0

efekt jest taki sam, jak "zsynchronizowane" i 'Object.wait(), Object.notify()' – irreputable

+0

'await()' odblokowuje się po wejściu i blokuje przy wychodzeniu. – irreputable

Odpowiedz

7

Sposób, w jaki należy go przeczytać, oznacza, że ​​wszystkie zapisy, które wystąpiły przed lock.unlock, są widoczne dla wszystkich kolejnych lock.lock. Wątek, który jest po przebudzeniu, w zasadzie będzie miał wartość lock.lock. Tak więc wszystkie zapisy, które miały miejsce od czasu poprzedniego odblokowania będą teraz widoczne.

signal nie ma semantyki pamięci, ponieważ twój ostatni punkt stwierdza, że ​​or when unlock() is called on the lock jest poprawny.

one oznaczają: „Udana operacja blokady ma te same pamięci efektów synchronizacji jak wprowadzenie zsynchronizowany blok”, i „A udana operacja odblokowania ma taką samą synchronizację pamięci skutki jak wyjściu bloku zsynchronizowanego”?

Tak, dokładnie! Dokładniej, kompilator wyda instrukcje kodu bajt monitorenter i monitororexit.

+1

Ok, dzięki. Czy mógłbyś również sprawdzić moją edycję? – FBB

+0

Dzięki za kompletną odpowiedź. – FBB