wood burning stoves 2.0*
The moose likes Threads and Synchronization and the fly likes Mystery associated with Volatile variables..... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Mystery associated with Volatile variables....." Watch "Mystery associated with Volatile variables....." New topic
Author

Mystery associated with Volatile variables.....

Sudarsan TS
Greenhorn

Joined: Jun 17, 2004
Posts: 9
So what exactly happens when you declare a variable volatile??

a) load, store, read, and write actions become atomic even for double and long declarations

b) a use action must have been preceded by a load action

c) a store action must have been preceded by an assign action

d) and as usual the main/shared memory has to service the requests of each of 'n' threads in exactly the same order.

Any more insights....

-sudarsan.
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
This is what the JLS says:

A field may be declared volatile, in which case a thread must reconcile its working copy of the field with the master copy every time it accesses the variable. Moreover, operations on the master copies of one or more volatile variables on behalf of a thread are performed by the main memory in exactly the order that the thread requested.


So, I think that you are imagining that "volatile" does a lot more than it does. For instance, I don't think it makes accesses to "double" fields atomic.

As the cost of "synchronized" has been reduced in newer JVMs, particularly when the lock is not contended, it is mostly better to use "synchronized", which is more obvious and more easily understood.

Although its meaning is rather similar to the "C" version, the Java "volatile" keyword cannot be used for the most common "C" usage: memory-mapped I/O. That's because you can't get real pointers in Java (and a good thing, too - mostly).


Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

The order of variable manipulation within a thread is one thing, how that manipulation is perceived by other threads is another.

If a variable is volatile, a seperate thread can never view a newer value of it before it could have viewed the old value. Some feel that the specification already provides for this. I was also convinced that it did.


In any even't there are only 2 uses of volatile.

1. That is to make long and double access atomic.
2. That is to make writes go directly to their variales, which is good only if you are writing to some hardware address. I would expect hardware i/o code to use volatile a lot.


Note: The decision to use synchronize is not in any way based on its efficiency or lack thereof. volatile and synchronized are not related and do not perform any interchangeable behaviors.
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
Originally posted by CL Gilbert:
In any even't there are only 2 uses of volatile.

1. ...

2. That is to make writes go directly to their variales, which is good only if you are writing to some hardware address. I would expect hardware i/o code to use volatile a lot.


Can you do that in Java? I didn't think so.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18914
    
  40

2. That is to make writes go directly to their variales, which is good only if you are writing to some hardware address. I would expect hardware i/o code to use volatile a lot.


The JVM has a couple of optimizations that may cache the value of variables. Volatile is necessary if multiple threads are trying to access a variable without synchronization -- which for 1.4 or eariler is generally used only for simple flags. For 1.5, more complex operations can be done with volatile variables with the atomic field updaters.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

Originally posted by Peter Chase:


Can you do that in Java? I didn't think so.


Really? I only had assumed that embedded java such as that running on cell phones and the like would provide this ability. If it does not then Java can never be used for any real time operations. And I doubt that is the case.
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

Originally posted by Henry Wong:


The JVM has a couple of optimizations that may cache the value of variables. Volatile is necessary if multiple threads are trying to access a variable without synchronization -- which for 1.4 or eariler is generally used only for simple flags. For 1.5, more complex operations can be done with volatile variables with the atomic field updaters.

Henry


While it is true that volatile will do this, I have never seen a case where it was advisable.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Hmmm, I originally meant to respond to this thread here, but in the course of my research I found this other thread slightly more appropriate for me. But my reply there seems reelvant here as well, so I thought I should provide this link.


"I'm not back." - Bill Harding, Twister
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18914
    
  40

Since this topic has somewhat detoured, let's take it further...

I have always been a fan of the "volatile" keyword -- not because it was useful, but because it "almost" was able to support an interesting area of threads programming. The area of optimistic programming.

Opimistic programming basically says that it is possible to fix race conditions by changing the algorithm -- that in theory, it is possible to remove all synchronization. It is certainly impossible to deadlock when the algorithm is optimistic ...

In any case, "volatile" almost was able to accomplish this. The only piece that was missing was an atomic conditional set operation. With the atomic libraries of JDK 1.5, optimistic programming is actually now possible. "volatile" is used under the covers for this.

We should see some really interesting uses of volatile variables starting with 1.5, especially as more developers get brave, and try optimistic programming.

Henry
[ November 28, 2004: Message edited by: Henry Wong ]
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

Volatile is for people of strong faith... and lucky rabbit's foot
[ November 28, 2004: Message edited by: CL Gilbert ]
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18914
    
  40

Originally posted by CL Gilbert:
Volatile is for people of strong faith... and lucky rabbit's foot


I don't know about faith, or luck. The techniques of dealing with threads optimistically has been around in the field of databases for more than a decade.

IMO, it is a matter of nerves, as optimistic algorithms can get really complicated.

Henry
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

Originally posted by Henry Wong:


I don't know about faith, or luck. The techniques of dealing with threads optimistically has been around in the field of databases for more than a decade.
...
Henry


How about as you said, Bravery

With the speed of computers today, you have to be really optimistic. I can't fathom an error that I am not notified about. I have to just assume its a facet of a production environment where speed is very very important as opposed to accuracy. I guess. Its hard to wrap my head around the idea of less than 100% accuracy. But i understand its a real thing. (e.g. we aren't all running with ECC RAM.)
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18914
    
  40

Originally posted by CL Gilbert:

With the speed of computers today, you have to be really optimistic. I can't fathom an error that I am not notified about. I have to just assume its a facet of a production environment where speed is very very important as opposed to accuracy. I guess. Its hard to wrap my head around the idea of less than 100% accuracy. But i understand its a real thing. (e.g. we aren't all running with ECC RAM.)


CL, I don't think I can fathom an error that I am not notified about either...

Optimistic programming techniques does not mean that there will be undetected errors. It means there will be errors in operations that historically, should not be any. For example, setting a common variable. You really have to be "brave" because the techniques can get really complicated, not only do you have to deal with error conditions, how the error occurs is also important.

For more info, try google "optimistic locking"...

Henry
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Mystery associated with Volatile variables.....