• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

locking and visibility question

 
Hendra Kurniawan
Ranch Hand
Posts: 239
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3028
10
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 179
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
R. Jain
Ranch Hand
Posts: 375
1
Java Python Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Pie
Posts: 20823
75
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic