Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Synchronized block, wait and memory model issues

 
Daniel Iwan
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone
My first post on JavaRanch ;)

I've been looking for an answer to my question for quite some time. No luck though...

Let's say one thread waits for changes of variable int "state".
First it enters synchronized block synchronized(guard) modifies "state" and releases lock of the guard object via guard.wait().
Now second thread modifies variable "state" also in synchronized block notifies first thread and leaves the block.
First thread resumes from wait() and checks the value of "state"

My question is. Does the "state" variable is being flushed to original location in memory from CPU registers
when wait() is called? In other words does thread 2 sees changes made by thread 1 before calling wait()?

I know that variables are "flushed" when synchronized block is reached and leaved but I'm not sure
about that wait() call. In theory wait() releases lock so all variables that has been modified and are in registers
should be flushed...

To clarify I'm talking about non-volatile variables.

Hope you can help me
Cheers
 
Jeff Storey
Ranch Hand
Posts: 230
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Daniel,

Your thought is correct. The memory is guaranteed to be flushed when a monitor is released, and wait does cause the monitor to be released. Another way to think of it is that when thread1 calls notify it must be in the synchronized block. So it must leave the synchronized block before thread2 can wake up and read the state variable. And when thread1 leaves the synchronized block, the memory will be flushed. I'm not sure of the exact semantics as to if it gets flushed when wait is called or when thread1 leaves the synchronized block or both, but the end result is that thread2 will see the updated value written by thread 1.

Jeff
 
Monu Tripathi
Rancher
Posts: 1369
1
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not sure if you have gone through the following already. Eitherways, what you have asked, IMO, has been addressed in the Visibilty Section of this page.

In essence, releasing a lock forces a flush of all writes from working memory employed by the thread, and acquiring a lock forces a (re)load of the values of accessible fields.


Hope that helps.
 
Daniel Iwan
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Cheers guys

That helps a lot

And thanks for the link Monu. Really helpful
 
Monu Tripathi
Rancher
Posts: 1369
1
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
you're welcome!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic