File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Threads and Synchronization and the fly likes locking and visibility question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "locking and visibility question" Watch "locking and visibility question" New topic
Author

locking and visibility question

Hendra Kurniawan
Ranch Hand

Joined: Jan 31, 2011
Posts: 239
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
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3012
    
  10
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.
Vishal Shaw
Ranch Hand

Joined: Aug 09, 2012
Posts: 179
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


Programming is about thinking, NOT coding
R. Jain
Ranch Hand

Joined: Aug 11, 2012
Posts: 375
    
    1

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...
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18763
    
  40

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


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: locking and visibility question