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 Typical use of volatile in Java Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Typical use of volatile in Java" Watch "Typical use of volatile in Java" New topic
Author

Typical use of volatile in Java

Tony Evans
Ranch Hand

Joined: Jun 29, 2002
Posts: 573
Trying to understand the volatile java keyword so wrote a basic programme based on example given
A typical example of a simple variable that is written to and read from different threads is a "stop request" flag allowing one thread to signal to another to finish:


The main calling code


Even though the volatileFlag is set to false in processB it is still set to true in processA this contradicts the examples given on the web.

Thanks for any help.
Tony Evans
Ranch Hand

Joined: Jun 29, 2002
Posts: 573
This is the unfinished example http://www.javamex.com/tutorials/synchronization_volatile_typical_use.shtml
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18757
    
  40

Tony Evans wrote:
Even though the volatileFlag is set to false in processB it is still set to true in processA this contradicts the examples given on the web.


So, you have a thread that looks at a variable -- in order to determine whether or not to stop running.

You never set that variable. The thread never stops. Make sense.

Where is the contradiction?

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

So: you created ProcessA and told it to start. Then you created ProcessB and told it to stop. You should not expect that to cause ProcessA to stop.

More practical example:

Tony Evans
Ranch Hand

Joined: Jun 29, 2002
Posts: 573
Thanks for the reply paul. The example you give will work for a volatile and non volatile boolean within a thread.

But I am trying to understand the use of volatile as regards the below:

A typical example of a simple variable that is written to and read from different threads is a "stop request" flag allowing one thread to signal to another to finish:


Every where I read it states that a volatile varaiable is stored in main memory not local to the thread. As I understand it we are talking about heap an stack the heap is shared by all threads , an if i understand right making a variable volatile even a primitive will put it on the heap not the local stack, Therefore a change should be refelected in all threads.

Thank s Tony
Tony Evans
Ranch Hand

Joined: Jun 29, 2002
Posts: 573
Hi Henry

the following code runs Process A then stops it from process B




The method stopFlag should halt the process even though its called from another process if its set to volatile
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18757
    
  40

Tony Evans wrote:Hi Henry

the following code runs Process A then stops it from process B




The method stopFlag should halt the process even though its called from another process if its set to volatile



Nope. The code is *not* what you described. The code is....

1. Your main thread creates a processA thread object, and starts a thread with it. You now have two threads -- the main thread and the processA thread.
2. Your main thread creates a processB thread object, but doesn't start a thread with it. You still only have two threads -- the main thread and the processA thread.
3. Your main thread sets the processB thread volatile variable, meaning that your main thread is trying to stop the processB thread. Since processB doesn't exist, it really doesn't do anything.

The processA variable has not been set, so the processA thread doesn't stop.

Henry
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18757
    
  40

Tony Evans wrote:
Every where I read it states that a volatile varaiable is stored in main memory not local to the thread. As I understand it we are talking about heap an stack the heap is shared by all threads , an if i understand right making a variable volatile even a primitive will put it on the heap not the local stack, Therefore a change should be refelected in all threads.


The volatile keyword doesn't change the location of anything. Variables on the heap are on the heap regardless of them being declared volatile or not. In your example, the volatileFlag variable is on the heap because it is an instance variable. Volatile has no affect on the location of the variables.

Henry
Tony Evans
Ranch Hand

Joined: Jun 29, 2002
Posts: 573
Thank you for your reply Henry , that is what I thought as well so in one scenario I did start process B then called stop, which stopped process B but did not stop process A.



The point of the exercise is to try an understand the use of the volatile keyword an how its used in inter thread communication.

To write a small programme that proves this

A typical example of a simple variable that is written to and read from different threads is a "stop request" flag allowing one thread to signal to another to finish:

Thanks for your help Tony
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18757
    
  40

Tony Evans wrote:Thank you for your reply Henry , that is what I thought as well so in one scenario I did start process B then called stop, which stopped process B but did not stop process A.




As you already figured out, your new example....

1. Your main thread creates a processA thread object, and starts a thread with it. You now have two threads -- the main thread and the processA thread.
2. Your main thread creates a processB thread object, and starts a thread with it. You now have three threads -- the main thread, the processA thread, and the processB thread.
3. Your main thread sets the processB thread volatile variable, meaning that your main thread is trying to stop the processB thread..... and processB stops.

The processA variable has not been set, so the processA thread doesn't stop.

Henry
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18757
    
  40

Tony Evans wrote:
To write a small programme that proves this

A typical example of a simple variable that is written to and read from different threads is a "stop request" flag allowing one thread to signal to another to finish:



... which you accomplished. In your latest example, your main thread stopped your processB thread.

Henry
Tony Evans
Ranch Hand

Joined: Jun 29, 2002
Posts: 573
Thanks Henry but stopping an changing the behaviour of threads an example below can be accomplished with a non volatile varaible, in fact in the small programmes I have written there is no difference.
I am trying to create a simple programme that shows theuse of a volatile varaible.


Code below no difference between volatile an non volatile boolean flag.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18757
    
  40

Tony Evans wrote:Thanks Henry but stopping an changing the behaviour of threads an example below can be accomplished with a non volatile varaible, in fact in the small programmes I have written there is no difference.
I am trying to create a simple programme that shows theuse of a volatile varaible.


Code below no difference between volatile an non volatile boolean flag.



Unfortunately, with your example, you will likely have zero chance to see any differences. Here is what volatile does...

1. It prevents the "register caching" optimization. Writes are immediately flushed to memory. Reads are always reloaded from memory.

However, this caching is ridiculously short lived as there is a very limited number of registers. It is rarely, if ever, cached across a method call. Never cached when blocked for I/O. Never cached while waiting or sleeping. etc...... this is mostly what your example program do. And even if it didn't, the short life of this caching is very difficult to notice directly.

2. It prevents some "code motion" optimization. This is the optimization used by the compiler/JVM to move code in and out of loops. And in and out of sync blocks.

Your example don't have any loops or sync blocks. And even if it did, this is not something that can be noticed directly.

3. For a 32bit JVM, longs and doubles are guaranteed to be atomic.

You don't have any longs or doubles in your example program. And even if it did, this is also something that is arguable very difficult to notice directly.


In other words, for your example, it probably doesn't matter if the variable is declared volatile or not -- although declaring it volatile is the *correct* thing to do.

Henry
Tony Evans
Ranch Hand

Joined: Jun 29, 2002
Posts: 573
Thanks for your help Henry its very hard with threads to prove some sort of behaviour, without setting up more complicated examples.

Thanks again for your help

Tony
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Typical use of volatile in Java