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 synchronized block Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "synchronized block" Watch "synchronized block" New topic
Author

synchronized block

Chris Hurst
Ranch Hand

Joined: Oct 26, 2003
Posts: 417
    
    2

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.


"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

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


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Chris Hurst
Ranch Hand

Joined: Oct 26, 2003
Posts: 417
    
    2

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.
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
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?


Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
Chris Hurst
Ranch Hand

Joined: Oct 26, 2003
Posts: 417
    
    2

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

Joined: Oct 26, 2003
Posts: 417
    
    2

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: synchronized block