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.googlegr oups.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******@gascad.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******@gascad.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******@gascad.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******@gascad.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

[Joe Seigh]

Greg wrote:

Joe Seigh wrote:

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

And here is an article stating otherwise
http://www.aristeia.com/Papers/DDJ_J...04_revised.pdf

--
Joe Seigh

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

[peter.koch.larsen]

Greg skrev:

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.

This is just plain nonsense. volatile is not needed for multithreaded
programming and gives no advantages whatsoever. This has been discussed
to death in comp.programming.threads.

/Peter

[Hans]

Joe Seigh wrote:

Greg wrote:

Joe Seigh wrote:

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.

[snip]
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

And here is an article stating otherwise
http://www.aristeia.com/Papers/DDJ_J...04_revised.pdf

--
Joe Seigh

Joe, I think the paper you quote does not support your case. It is a
description of how the keyword volatile in *one special case* (namely
when one tries to avoid locking an object before reading it) will not
help. To use this example to infer that volatile *never* is of use in
thread programming is plain wrong.

Here is an example of when volatile can be handy:
volatile int sharedVariable = 0;

void dummyFcn()
{
}

void thread1() // This thread is run first
{
while (sharedVariable == 0)
{
dummyFcn();
}
// Continue doing more interesting things
}
void thread2() // After a while, this thread is allowed to cut in
{
// Do lots of other things, irrelevant for this study
sharedVariable = 5;
}
Now what would happen with thread1 if sharedVariable was not volatile?
Without optimization there would probably be no problem. The compiler
would suspect dummyFcn might well modify sharedVariable, and thus
reload it before each comparison.

However, as stated in the paper you referenced, an optimizing compiler
might well be smart enough to inline dummyFcn, even though it is not
specified to be inlined. In such a case, the compiler will discover
that sharedVariable is not modified, and never reload it.

Thus, volatile is required (and sufficient) for the two threads to
communicate properly.

[Joe Seigh]

Hans wrote:

Joe Seigh wrote:

Greg wrote:

Joe Seigh wrote:

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.

[snip]
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

And here is an article stating otherwise
http://www.aristeia.com/Papers/DDJ_J...04_revised.pdf

--
Joe Seigh

Joe, I think the paper you quote does not support your case. It is a
description of how the keyword volatile in *one special case* (namely
when one tries to avoid locking an object before reading it) will not
help. To use this example to infer that volatile *never* is of use in
thread programming is plain wrong.

Here is an example of when volatile can be handy:
volatile int sharedVariable = 0;

void dummyFcn()
{
}

void thread1() // This thread is run first
{
while (sharedVariable == 0)
{
dummyFcn();
}
// Continue doing more interesting things
}
void thread2() // After a while, this thread is allowed to cut in
{
// Do lots of other things, irrelevant for this study
sharedVariable = 5;
}
Now what would happen with thread1 if sharedVariable was not volatile?
Without optimization there would probably be no problem. The compiler
would suspect dummyFcn might well modify sharedVariable, and thus
reload it before each comparison.

However, as stated in the paper you referenced, an optimizing compiler
might well be smart enough to inline dummyFcn, even though it is not
specified to be inlined. In such a case, the compiler will discover
that sharedVariable is not modified, and never reload it.

Thus, volatile is required (and sufficient) for the two threads to
communicate properly.

For correctness, not forward progress which is what you are talking
about. If your program does not work correctly if instead you used

while (rand() == 0)
{
dummyFcn();
}

then you are doing something wrong.

--
Joe Seigh

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

[Hans]

Joe Seigh wrote:

Hans wrote:

Joe Seigh wrote:

Greg wrote:

Joe Seigh wrote:

>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.
>

[snip]

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
And here is an article stating otherwise
http://www.aristeia.com/Papers/DDJ_J...04_revised.pdf

--
Joe Seigh

Joe, I think the paper you quote does not support your case. It is a
description of how the keyword volatile in *one special case* (namely
when one tries to avoid locking an object before reading it) will not
help. To use this example to infer that volatile *never* is of use in
thread programming is plain wrong.

Here is an example of when volatile can be handy:
volatile int sharedVariable = 0;

void dummyFcn()
{
}

void thread1() // This thread is run first
{
while (sharedVariable == 0)
{
dummyFcn();
}
// Continue doing more interesting things
}
void thread2() // After a while, this thread is allowed to cut in
{
// Do lots of other things, irrelevant for this study
sharedVariable = 5;
}
Now what would happen with thread1 if sharedVariable was not volatile?
Without optimization there would probably be no problem. The compiler
would suspect dummyFcn might well modify sharedVariable, and thus
reload it before each comparison.

However, as stated in the paper you referenced, an optimizing compiler
might well be smart enough to inline dummyFcn, even though it is not
specified to be inlined. In such a case, the compiler will discover
that sharedVariable is not modified, and never reload it.

Thus, volatile is required (and sufficient) for the two threads to
communicate properly.

For correctness, not forward progress which is what you are talking
about. If your program does not work correctly if instead you used

while (rand() == 0)
{
dummyFcn();
}

then you are doing something wrong.

--
Joe Seigh

Joe, I am afraid you have me confused here. Do you think you could
elaborate a bit on what you are saying? Why must I be able to handle
putting a call to rand() in my code? And what do you mean by the terms
"correctness" and "forward progress"?

[Joe Seigh]

Hans wrote:

Joe Seigh wrote:

For correctness, not forward progress which is what you are talking
about. If your program does not work correctly if instead you used

while (rand() == 0)
{
dummyFcn();
}

then you are doing something wrong.

--
Joe Seigh

Joe, I am afraid you have me confused here. Do you think you could
elaborate a bit on what you are saying? Why must I be able to handle
putting a call to rand() in my code? And what do you mean by the terms
"correctness" and "forward progress"?

Correctness means whether your program produces a correct result.
Forward progress determines whether your program completes within
a certain amount of time.

If your code logic can't handle rand() then you are trying to signal
some data condition which must be synchronized correctly by pthread
synchronization not by volatile which will do nothing.

About the only valid use of volatile would be to prematurely terminate
a long running computation which would produce no result or a partial
result. Calling rand() would have the same effect.

--
Joe Seigh

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

[Jerry Coffin]

Hans wrote:

[ ... ]

Joe, I think the paper you quote does not support your case. It is a
description of how the keyword volatile in *one special case* (namely
when one tries to avoid locking an object before reading it) will not
help. To use this example to infer that volatile *never* is of use in
thread programming is plain wrong.

Here is an example of when volatile can be handy:
I'm afraid I disagree.
volatile int sharedVariable = 0;

void dummyFcn()
{
}

void thread1() // This thread is run first
{
while (sharedVariable == 0)
{
dummyFcn();
}
// Continue doing more interesting things
}
void thread2() // After a while, this thread is allowed to cut in
{
// Do lots of other things, irrelevant for this study
sharedVariable = 5;
}

Now what would happen with thread1 if sharedVariable was not volatile?
Without optimization there would probably be no problem. The compiler
would suspect dummyFcn might well modify sharedVariable, and thus
reload it before each comparison.
Even if (for whatever reason) the compiler decided not to generate code
for dummyFcn inline, it could generate a list of globals it modifies
(empty) and deduce that it would enregister sharedVariable.

Unfortunately, making the variable volatile doesn't guarantee correct
operation either. Modifying the variable isn't guaranteed to be atomic,
so the assignment to sharedVariable might take two or more instructions
to finish (e.g. even on an 8-bit processor, int must still be at least
16 bits). In a case like this, execution can be interrupted between the
instructions that carry out the single assignment, leaving an
indeterminate value in the variable. (e.g. assigning 0x1234 to a 16-bit
int that contained 5 might easily get interrupted when it had a value
of 0x1205 or 0x0034).

As far as C++ cares, this isn't a problem, because it only places
requirements on the value at sequence points, not between them. For
multithreading, the story is entirely different though -- it can
interrupt execution anytime, not just at sequence points.

To have even a _hope_ of correct operation, you probably want to use a
sig_atomic_t instead of an int. This gives you a pretty good chance,
because the circumstances under which you can switch threads are
usually pretty similar (if not identical) to those under which you can
deliver a signal. That's not guaranteed by anything though -- it's just
how things frequently work out.

[ ... ]
Thus, volatile is required (and sufficient) for the two threads to
communicate properly.

No, it is not. Along with size, alignment can play a role in ensuring
atomic assignments -- e.g. assigning a 32-bit value to a 32-bit
variable on a 32-bit machine still often won't be atomic if the
variable is mis-aligned.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Old Wolf]

Jerry Coffin wrote:

Hans wrote:

Joe, I think the paper you quote does not support your case. It is a
description of how the keyword volatile in *one special case* (namely
when one tries to avoid locking an object before reading it) will not
help. To use this example to infer that volatile *never* is of use in
thread programming is plain wrong.

Here is an example of when volatile can be handy:
I'm afraid I disagree.

volatile int sharedVariable = 0;
void thread1() // This thread is run first
{
while (sharedVariable == 0)
dummyFcn();
// Continue doing more interesting things
}

void thread2() // After a while, this thread is allowed to cut in
{
// Do lots of other things, irrelevant for this study
sharedVariable = 5;
}

Now what would happen with thread1 if sharedVariable was not volatile?
Without optimization there would probably be no problem. The compiler
would suspect dummyFcn might well modify sharedVariable, and thus
reload it before each comparison.

Unfortunately, making the variable volatile doesn't guarantee correct
operation either. Modifying the variable isn't guaranteed to be atomic,
so the assignment to sharedVariable might take two or more instructions
to finish (e.g. even on an 8-bit processor, int must still be at least
16 bits). In a case like this, execution can be interrupted between the
instructions that carry out the single assignment, leaving an
indeterminate value in the variable. (e.g. assigning 0x1234 to a 16-bit
int that contained 5 might easily get interrupted when it had a value
of 0x1205 or 0x0034).

As far as C++ cares, this isn't a problem, because it only places
requirements on the value at sequence points, not between them. For
multithreading, the story is entirely different though -- it can
interrupt execution anytime, not just at sequence points.

As far as C++ cares, there is only a single thread.
When discussing this issue, we are going beyond the bounds
of what the C++ Standard dictates.

So, supposing you know that your architecture performs
this write atomically (or even if you're on a non-pre-emptive
system such that you know where the thread switch is going to
occur), what is wrong with this code example?
To have even a _hope_ of correct operation, you probably want to use a
sig_atomic_t instead of an int.

I've heard people claim that even a sig_atomic_t write is not
guaranteed to be an atomic operation, if you are not actually
in a signal handler.