volatile variables

[Radde]

HI,
Can volatile variables be accessed by many processess..or only one
process can access it..

Cheers..

[benben]

"Radde" <ms******@gmail .com> wrote in message
news:11******** **************@ o13g2000cwo.goo glegroups.com.. .

HI,
Can volatile variables be accessed by many processess..or only one
process can access it..

Cheers..

Many, it is just a variable not to be optimized away.

Ben

[Radde]

Can u be more eloborate on that..

[benben]

The only difference between a volatile and a non-volatile variable, as far
as I know, is that the non-volatile one has a chance to be totally
eliminated by the optimizing compiler. A few operations does depend on the
existence of certain variables while the compiler can't deduce at compile
time, and that's why you need to tell the compiler so by using the
"volatile" keyword.

This has no direct connection with accessing the variable from multiple
processors. Of course, the variable needs to exists in order to be accessed.

ben

[Karl Heinz Buchegger]

benben wrote:

The only difference between a volatile and a non-volatile variable, as far
as I know, is that the non-volatile one has a chance to be totally
eliminated by the optimizing compiler.

Well. Not exactly.
volatile tells the compiler that this variable can get altered by ways that
the compiler cannot deduce. As a consequence, the compiler will exclude that
variable from optimizations and the code will always fetch the variables content
from memory, even if it has done so before (no caching).

Imagine a hardware clock which is mapped into memory. You need some way to
tell the compiler: whenever I access that variable (mapped to the hardware
clock), I want you to actually fetch the content from there. Otherwise the
compiler might just ask the clock once for the current time and use the
cached value (in a processor register) throught the rest of the program.

--
Karl Heinz Buchegger
kb******@gascad .at

[Joe Seigh]

Karl Heinz Buchegger wrote:

benben wrote:

The only difference between a volatile and a non-volatile variable, as far
as I know, is that the non-volatile one has a chance to be totally
eliminated by the optimizing compiler.

Well. Not exactly.
volatile tells the compiler that this variable can get altered by ways that
the compiler cannot deduce. As a consequence, the compiler will exclude that
variable from optimizations and the code will always fetch the variables content
from memory, even if it has done so before (no caching).

Imagine a hardware clock which is mapped into memory. You need some way to
tell the compiler: whenever I access that variable (mapped to the hardware
clock), I want you to actually fetch the content from there. Otherwise the
compiler might just ask the clock once for the current time and use the
cached value (in a processor register) throught the rest of the program.

But it doesn't guarantee atomic reads. A non-atomic read of the clock could
be problematic.

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

[Fred Zwarts]

"Karl Heinz Buchegger" <kb******@gasca d.at> wrote in message news:43******** *******@gascad. at...

volatile tells the compiler that this variable can get altered by ways that
the compiler cannot deduce. As a consequence, the compiler will exclude that
variable from optimizations and the code will always fetch the variables content
from memory, even if it has done so before (no caching).

This brings up my question: What exactly means "the compiler cannot deduce"?
I'm thinking of a multi-treaded program in which one thread modifies a variable
and another thread reads the variable.

If the whole code is contained in one source file, is it then necessary to make this
variable volatile, or will the compiler be able to deduce that the value of the
variable may be changed in between two read operations in the second thread.

I have the feeling that one should not expect that a compiler takes multi-threading
into account. But I do not know an exact description of "the compiler cannot deduce".

(I know that a call to a function (e.g. to lock/unlock a mutex) is sufficient to tell the compiler
that a variable could be changed, so in practice volatile is not often needed because
multi-threaded programs already use function calls to synchronize their access to
variables.)

F.Z.

[Greg]

Fred Zwarts wrote:

"Karl Heinz Buchegger" <kb******@gasca d.at> wrote in message news:43******** *******@gascad. at...

volatile tells the compiler that this variable can get altered by ways that
the compiler cannot deduce. As a consequence, the compiler will exclude that
variable from optimizations and the code will always fetch the variables content
from memory, even if it has done so before (no caching).

This brings up my question: What exactly means "the compiler cannot deduce"?
I'm thinking of a multi-treaded program in which one thread modifies a variable
and another thread reads the variable.

If the whole code is contained in one source file, is it then necessary to make this
variable volatile, or will the compiler be able to deduce that the value of the
variable may be changed in between two read operations in the second thread.

I have the feeling that one should not expect that a compiler takes multi-threading
into account. But I do not know an exact description of "the compiler cannot deduce".

(I know that a call to a function (e.g. to lock/unlock a mutex) is sufficient to tell the compiler
that a variable could be changed, so in practice volatile is not often needed because
multi-threaded programs already use function calls to synchronize their access to
variables.)

F.Z.

A volatile object is one whose value can change asynchronously to the
program's sequence of instructions. For most variables a program can be
sure that the variable's value cannot change except when the program
executes an instruction in its instruction sequence to change it. But
since the value of a volatile variable can change at times that are not
deducible from the program's instruction sequence, the program must
read its value every time that the program uses it. Note that it is
possible to have a const volatile variable. A const volatile variable
would be one whose value can change at any time, but also one whose
value cannot be changed by the program running.

A preemptively multithreaded program should declare any variables
shared between threads as volatile. Each of the program's thread's
sequence of instructions is outside of the instruction sequence
executing on any other thread. A program should also use the "volatile"
keyword on any member functions that are OK to call for a volatile
instance of a class. In fact the "volatile" keyword is pretty much a
parallel of the "const" keyword - for example function parameters can
be declared volatile, just as they can be declared const.

Greg

[Joe Seigh]

Fred Zwarts wrote:

"Karl Heinz Buchegger" <kb******@gasca d.at> wrote in message news:43******** *******@gascad. at...

volatile tells the compiler that this variable can get altered by ways that
the compiler cannot deduce. As a consequence, the compiler will exclude that
variable from optimizations and the code will always fetch the variables content
from memory, even if it has done so before (no caching).

This brings up my question: What exactly means "the compiler cannot deduce"?
I'm thinking of a multi-treaded program in which one thread modifies a variable
and another thread reads the variable.

If the whole code is contained in one source file, is it then necessary to make this
variable volatile, or will the compiler be able to deduce that the value of the
variable may be changed in between two read operations in the second thread.

I have the feeling that one should not expect that a compiler takes multi-threading
into account. But I do not know an exact description of "the compiler cannot deduce".

(I know that a call to a function (e.g. to lock/unlock a mutex) is sufficient to tell the compiler
that a variable could be changed, so in practice volatile is not often needed because
multi-threaded programs already use function calls to synchronize their access to
variables.)

Volatile has no meaning as far as threaded programs are concerned. So you cannot
infer any useful portable behavior from volatile w.r.t. threading.

Any necessary behavior required to make a threaded program work is covered by
Posix compliance for that compiler and only covers pthread functions. Volatile
is not affected by Posix compliance. It's still meaningless. It has no effect
on the correctness of threaded programs. If you think volatile is required to
make your threaded program correct then you most certainly have an error in your
program logic.

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

[Greg]

Joe Seigh wrote:

Fred Zwarts wrote:

"Karl Heinz Buchegger" <kb******@gasca d.at> wrote in message news:43******** *******@gascad. at...

volatile tells the compiler that this variable can get altered by ways that
the compiler cannot deduce. As a consequence, the compiler will exclude that
variable from optimizations and the code will always fetch the variables content
from memory, even if it has done so before (no caching).

This brings up my question: What exactly means "the compiler cannot deduce"?
I'm thinking of a multi-treaded program in which one thread modifies a variable
and another thread reads the variable.

If the whole code is contained in one source file, is it then necessary to make this
variable volatile, or will the compiler be able to deduce that the value of the
variable may be changed in between two read operations in the second thread.

I have the feeling that one should not expect that a compiler takes multi-threading
into account. But I do not know an exact description of "the compiler cannot deduce".

(I know that a call to a function (e.g. to lock/unlock a mutex) is sufficient to tell the compiler
that a variable could be changed, so in practice volatile is not often needed because
multi-threaded programs already use function calls to synchronize their access to
variables.)

Volatile has no meaning as far as threaded programs are concerned. So you cannot
infer any useful portable behavior from volatile w.r.t. threading.

Any necessary behavior required to make a threaded program work is covered by
Posix compliance for that compiler and only covers pthread functions. Volatile
is not affected by Posix compliance. It's still meaningless. It has no effect
on the correctness of threaded programs. If you think volatile is required to
make your threaded program correct then you most certainly have an error in your
program logic.

--
Joe Seigh

The volatile keyword has the same meaning in any C++ program. The
volatile keyword does not state how the value can change asynchronously
- be it by an interrupt, a signal, memory-mapped I/O, or by another
thread running in the same process.

Since C++ has no concept of multiple threads, it has no way of
coordinating instruction sequences between threads. Therefore one
thread changing a shared variable is to the other threads an
asynchronous change. Such a variable should therefore be declared
volatile to prevent the program running on any thread from caching its
value.

There is certainly plenty of literature describing the importance of
the volatile keyword to multithreaded programming. Here is one such
article:

http://www.cuj.com/documents/s=7998/...p1902alexandr/

Greg