aspose file tools*
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
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "boolean and lock?" Watch "boolean and lock?" New topic
Author

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.

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

Joined: Nov 05, 2000
Posts: 761


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: 3007
    
    9
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: http://aspose.com/file-tools
 
subject: boolean and lock?