• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Synchronized block, wait and memory model issues

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Ranch Hand
Posts: 230
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Rancher
Posts: 1369
1
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
you're welcome!
 
Don't listen to Steve. Just read this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic