• 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

 
Ranch Hand
Posts: 443
3
Eclipse IDE C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hopefully dumb question ;-) I tried reading the JSL but I must have missed it. When using a synchronized block, ignoring the locking aspect and thinking in terms of synchronizing the threads view of memory as a communication aid between threads, what guarantees do you get ..

e.g.

// this thread may not have the latest annotherObject here (cached)

synchronized (lockobject)// B:
{
// A: use other (non volatile) member variable here
// (obviously not locked)
if (annotherObject != null)
{
System.out.println ("its null");
}
}

i.e.

when synchronized is called does it sync all threads view of memory, or is it limited to the object being locked in some way i.e. provided another thread doesn't change annotherObject between A: and B: will its value be correct (current always\non cached)at B: or is it still possible to see a stale (cached) value of annotherObject as it itselft isn't locked or was it sync'ed in terms of its value when we entered the synchronized block, like it was volatile at that point i.e. did it drop the threads cached view of the world (if it had one).

Just to be clear I'm quite clear on what's locked and isn't (i.e. you can assume any other thread changing anotherObject must enter a synchronized lockObject block) , I just need a bit clearer view of how thread caching can work and when the thread is guaranteed to have the true latest version of a non locked variable. I hope that makes sense.
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are many triggers that will force the flushing of registers (and / or reload). Synchronization boundaries are one of them.

So, if two threads are synchronizating on the same lock, they should be in synch -- as it is guaranteed that one thread must release the lock before the other can acquire it.

Henry
 
Chris Hurst
Ranch Hand
Posts: 443
3
Eclipse IDE C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok but does that mean all threads are 'flushed' at the synchronized block, I presume then a thread synchronizing on any object flushes any cached view of anything it might have but does that still potentially leave stale (unflushed) views in the other threads or are they forced to flush even though they are not synchronizing at that instant, basically in my example I'm trying to get at should annotherObject be volatile i.e. at the sequence point for the synchronized block will this thread see the absolute latest version from all threads of an object its not synchronizing on.
 
Ranch Hand
Posts: 1970
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Surely the question shouldn't arise, in a well-written program.

Threads that are working on shared data should use synchronisation to ensure they interact correctly. Entering or exiting synchronisation flushes those threads' caches, ensuring they see the right data.

Threads that do not participate in the synchronisation scheme should not be accessing data that is protected by the synchronisation scheme. Therefore, who cares whether they would theoretically see latest or cached versions of it?
 
Chris Hurst
Ranch Hand
Posts: 443
3
Eclipse IDE C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Your right the question doesn't arise in a well written program however ...

i) Exams \interview questions like the SCJP for example often ask questions of the form given this snippet of code which you would never ever write does it do a) b) c) or d) which is one of the arguments I've heard against such tests (not my argument) i.e. saying who cares just write it properly isn't an option.

ii) I usually find myself inheriting code and the cost of rewriting can often be huge due to the testing involved and at the very least I'ed need to prove it is wrong even if just in theory rather than it just say it looks wrong so I changed it.

iii) I like to understand things I find it sticks better in my mind.
 
Chris Hurst
Ranch Hand
Posts: 443
3
Eclipse IDE C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Anyway I digress, I eventually found some very good web pages that explain it all in detail (can I post links here to other web pages or is that a forum no,no), I'll include the main note in case it helps any one else, in short it appears (I assume a credited quote is ok)...

"Synchronization ensures that memory writes by a thread before or during a synchronized block are made visible in a predictable manner to other threads which synchronize on the same monitor. After we exit a synchronized block, we release the monitor, which has the effect of flushing the cache to main memory, so that writes made by this thread can be visible to other threads. Before we can enter a synchronized block, we acquire the monitor, which has the effect of invalidating the local processor cache so that variables will be reloaded from main memory. We will then be able to see all of the writes made visible by the previous release."

JSR 133 (Java Memory Model) FAQ
Jeremy Manson and Brian Goetz, February 2004

... all obvious now.
reply
    Bookmark Topic Watch Topic
  • New Topic