Forums Register Login

locking and visibility question

+Pie Number of slices to send: Send
I quote from Java Concurrency in Practice:

Intrinsic locking can be used to guarantee that one thread sees the effects of another in a predictable manner, as illustrated by Figure 3.1. When thread A executes a synchronized block, and subsequently thread B enters a synchronized block guarded by the same lock, the values of variables that were visible to A prior to releasing the lock are guaranteed to be visible to B upon acquiring the lock. In other words, everything A did in or prior to a synchronized block is visible to B when it executes a synchronized block guarded by the same lock. Without synchronization, there is no such guarantee.



what does locking have to do with visibility anyway?

in this code:


does the quote imply that if thread B does not enter the synchronized block, it won't be able to read value of x that's updated earlier by thread A? thanks
+Pie Number of slices to send: Send
 

Hendra Kurniawan wrote:does the quote imply that if thread B does not enter the synchronized block, it won't be able to read value of x that's updated earlier by thread A? thanks


It doesn't mean you won't be able to, but you're not guaranteed to be able to. If you're accessing mutable data outside a sync block, weird stuff can happen, and we just don't know what will happen. But one of the possibilities is that nothing weird happens at all, and everything works exactly as you might expect. If that happens, great - but do not expect this to happen all the time.
+Pie Number of slices to send: Send
Hi,

Without locking, the mutable data is not going be consistent, in a multiple thread environment. Consider removing line no.5 from your code. Now if two threads concurrently works on line 5 , then Dirty Read problem may occur.

As for this,

does the quote imply that if thread B does not enter the synchronized block, it won't be able to read value of x that's updated earlier by thread A



Before syncronized block I can see only initialization of x, that not a problem as x is always going to give you the same value before the synchronized block. The problem point is when the same variable is concurrently updated by one thread and read/updated by other. So in that case we have to prevent another lock on that variable if it already has a Write lock
+Pie Number of slices to send: Send
 

Hendra Kurniawan wrote:I quote from Java Concurrency in Practice:

Intrinsic locking can be used to guarantee that one thread sees the effects of another in a predictable manner, as illustrated by Figure 3.1. When thread A executes a synchronized block, and subsequently thread B enters a synchronized block guarded by the same lock, the values of variables that were visible to A prior to releasing the lock are guaranteed to be visible to B upon acquiring the lock. In other words, everything A did in or prior to a synchronized block is visible to B when it executes a synchronized block guarded by the same lock. Without synchronization, there is no such guarantee.



what does locking have to do with visibility anyway?

does the quote imply that if thread B does not enter the synchronized block, it won't be able to read value of x that's updated earlier by thread A? thanks


No, it says that the value of variable will be same for thread B entering the synchronized block as it was when thread A left the synchronized block..
IF Both the thread are synchronizing on same lock...
In other words, Intrinsic locking guarantees that, the value of variable is not modified by any other thread, in the time between, thread A leaving the synchonized block
and thread B entering the synchronized block with same lock...
+Pie Number of slices to send: Send
 

R. Jain wrote:In other words, Intrinsic locking guarantees that, the value of variable is not modified by any other thread, in the time between, thread A leaving the synchonized block
and thread B entering the synchronized block with same lock...




No. This isn't exactly true. It is certainly passible for another thread, say thread C, to grab the lock between the release by thread A, and the grab by lock B. Of course, this will prevent thread B from entering until thread C releases the lock.

Henry
Won't you please? Please won't you be my neighbor? - Fred Rogers. Tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 1056 times.
Similar Threads
Understanding Volatile & Synchronized Visibility
A set of questions on concurrency.
Questions about the fixed "volatile" keyword
Synchronized blocks
Volatile Variable
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 03:11:15.