Re: Question about volatile modifier

[Curt Smith <chsmith@speakeasy.net>]

The byte code spec is still at 1.0, meaning there's been no new data 
type changes
since JDK 1.0.  There's been changes that looked like language changes 
like inner classes
and assert etc but actually these still fit into the existing spec for 
byte code.

Volatile was apart of C / C++ and migrated to Java.  I don't have a 1.0 
language
spec, but I'd guess it was in there.   Volatile still has a useful if 
not seldom used function in
managing the compile time optimizer and run time optimizers and in 
concurrency.

Some method variables completely disappear during compile time optimization
(does the -O flag do anything these days?) and run time optimization. 
 This makes
it imposible to set break points or watch points should this happen.  Ok 
still not
very interesing!

For concurrency, some data types like long (I think this is the only 
data type
so affected) become atomic when declared as volatile.  Atomic, what do you
mean?

This means:

volatile long shared_var_with_other_threads;

That one thread setting this var with a new value, that another thread 
that uses
this value will ALWAYS read a consistant value.  (the correct value). 
 Remember
that long is 64 bits and most of our desktop CPUs are still 32bit and 
need two instructions
to load a 64 bit variable.  The P4 VM and 64 Sparc VMs may have reduced 
this to
a single (atomic) instruction with VM's for those CPUs.   Not setting 
this long to
volitile would be posible for the reading thread to read a half set new 
value, due to
time slicing and it requireing two or more non-atomic machine 
instructions etc.

A side issue of concurrency, tricks and higher performance designs, 
involves the
concept of atomic operations.   Setting an object refrence to a new 
object _is_
atomic.  Meaning, if your business logic remains consistant, you can 
share objects
between threads, and change those object refrences without inconsistancy 
at the
language level.

I.E.

myStateVar = new StateVar(param, param);

If myStateVar is shared between threads, all readers will access a 
consistant
object reference.  So no synchronize/notify is needed if changing the 
state is
your only need and threads still holding or accessing the previous state 
object
is ok for your business logic.  The later statement is really your main 
decission
with this higher perf. (but potientially dangerous to your logic) 
technique of
sharing objects between threads.

Anyone have more to add to what volatile might be useful for?

curt



Lee Chalupa wrote:

> Hello:
>
> I am looking for some perspective concerning the use of the volatile 
> modifier.
>
> I noticed that Mughal's book on certification doesn't cover the 
> volatile modifier in his coverage of Threads.  That doesn't seem to 
> make much sense.
> Is this an oversight or does he know something that I don't?
>
> Does anyone have an explanation of why this could be?
>
> Also, does anyone know if there have been any recent changes to the 
> JVM spec or to the Java language spec.
> that would account for a change in the importance of the volatile 
> modifier?
>
> Thanks.
>
> lee
>
>

-- 

Curt Smith
chsmith@speakeasy.net
(w) 404-463-0973
(h) 404-294-6686