This week's book giveaway is in the Jobs Discussion forum.
We're giving away four copies of Java Interview Guide and have Anthony DePalma on-line!
See this thread for details.
The moose likes Threads and Synchronization and the fly likes boolean and lock? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "boolean and lock?" Watch "boolean and lock?" New topic

boolean and lock?

Robert Kennedy
Ranch Hand

Joined: Jun 27, 2008
Posts: 63
I have a static boolean which is read by many threads but only set by one. Is it necessary to wrap accesses to the boolean in a synchronize(myLock) block.

It is not imperative that a reading thread sees a change which occurred concurrently, it will pick it up one second later.

[ September 02, 2008: Message edited by: Robert Kennedy ]
Pho Tek
Ranch Hand

Joined: Nov 05, 2000
Posts: 782

It is not imperative that a reading thread sees a change which occurred concurrently

If you have concurrency constructs which will ensure that your reading threads see the change the microsecond that it happens, why not use it ?

You don't need to synchronized.
Use a volatile if the boolean value goes from one state to another and no mutation occurs after that.
Otherwise an AtomicBoolean will help.
victor kamat
Ranch Hand

Joined: Jan 10, 2007
Posts: 247
You may consider making the boolean variable volatile
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3028
To answer the original question as asked: if only one thread is writing, and if you really don't care if some of the reader threads see an old value, then... well even then, you may need to synchronize, or us volatile, or an AtomicBoolean. If you don't do any of these, then there is still a danger that other threads may see the changed value before you think they should be able to (i.e. before the setting thread has completed all the operations it's supposed to). This may seem impossible, but the compiler and JIT are allowed to reorder operations for efficiency if it can be proven programmatically that the reordering will not affect the thread that is executing the code. A simple example:

This seems reasonable. But a JIT may decide to reorder the initialize() method as:

After all, this would clearly make no difference to a single thread. None of the lines of code depend on each other, and it should make no difference if they are reordered. Unless another thread comes along and concurrently tries to read values of isInitialized, x, y, and/or z. That's when problems occur.

Admittedly, in this example, there's no good reason apparent why the JIT might want to make this particular "optimization". But it can happen, with more complex examples. The general point is that with multiple threads, really weird things can happen unless you carefully protect any mutable data that's accessible from more than one thread.
[ August 29, 2008: Message edited by: Mike Simmons ]
I agree. Here's the link:
subject: boolean and lock?
It's not a secret anymore!