what is volatile?

Normally the JVM can optimise access to variables, for example if a variable is used frequently in a particular piece of code it might copy it to a hardware register for the duration.

volatile says that it's not to do that. Always to read or write the variable directly at it's memory address.

It's saying a variable may change unexpectedly, for example it might be changed by a piece of native code outside the direct control of the JVM.

Some people believe that inter thread communications variables should be volatile, but I've never come accross a case where I can see it helping; if there are possible timing problems you really need synchronized (and synchronized automatically deals with caching issues).

malcolmmca at 2007-7-14 22:00:22 >

as they told volaile is avarible which can change its state9value0 with out notice of current application,

ex:

if u are using time variable(System time) it should be volatile , becuse the value of the variable changed by the extenal element.

volatile variable tell to the compiler that value of the variable changed

externly.

uuuua at 2007-7-14 22:00:22 >

> as they told volaile is avarible which can change its

> state9value0 with out notice of current application,

>

>

No, that's not what was said.

> ex:

>

> if u are using time variable(System time) it should

> be volatile , becuse the value of the variable

> changed by the extenal element.

>

> volatile variable tell to the compiler that value of

> the variable changed

> externly.

No, that's not what it's for.

jverda at 2007-7-14 22:00:22 >

> volatile is meant for variable can be changed by

> threads frequently.

No, that's not what it's for.

> somebody say that volatile variables are helpful to

> inbetween thread comunication but actually it will

> not happen.

If the VM implements it properly it will.

> in real time code execution the varables having

> 64bytes can be lost their values because they are

> used in thread comunication and 64 bytes are stored

> in two fold prosses .

I'm not sure whether volatile will handle doubles and longs atomically, but even if it doesn't, it still works for other types (assuming the VM is correctly implemented--many older ones weren't, I hear).

> i hope this may help you

No, it won't.

vanilla_loraxa at 2007-7-14 22:00:22 >

> >

> > I'm not sure whether volatile will handle doubles

> and

> > longs atomically, but even if it doesn't, it still

> > works for other types (assuming the VM is

> correctly

> > implemented--many older ones weren't, I hear).

> >

>

> declaring volatile would handle long and double write

> operations atomically

Yup.

[url http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.7]JLS 17.7 Non-atomic Treatment of double and long[/url]

Some implementations may find it convenient to divide a single write action on a 64-bit long or double value into two write actions on adjacent 32 bit values. For efficiency's sake, this behavior is implementation specific; Java virtual machines are free to perform writes to long and double values atomically or in two parts.

For the purposes of the Java programming language memory model, a single write to a non-volatile long or double value is treated as two separate writes: one to each 32-bit half. This can result in a situation where a thread sees the first 32 bits of a 64 bit value from one write, and the second 32 bits from another write. Writes and reads of volatile long and double values are always atomic. Writes to and reads of references are always atomic, regardless of whether they are implemented as 32 or 64 bit values.

jverda at 2007-7-14 22:00:22 >

> Hmm,

> As long as you do not specify variable as a final

> variable, the variable is volatile as it is

> understood from its name.

>

> Message was edited by:

> samue-1

why are you misguiding the forum users when you have no idea of what it is, and what you are talking about.

kilyasa at 2007-7-21 10:21:50 >