use of keyword volatile in multi-threaded C++ program

[C++Liliput]

It seems that the keyword "volatile" is used to make sure that threads
reading (or writing to) the same data should see a consistent picture
of the variable i.e. updates made to the common data should
immediately get reflected to other threads that are using it. However
I have never faced this issue in y multi-threaded code even though the
common variables are not declared volatile. So is this just a matter
of coincidence that I have had no runtime issues or is it that the
"volatile" keyword is required in some special situations that perhaps
my code does not encounter? I would love to know a demonstrable piece
of code that really shows the relevance of volatile variables in multi-
threaded environment.

[red floyd]

Re: use of keyword volatile in multi-threaded C++ program

C++Liliput wrote:

It seems that the keyword "volatile" is used to make sure that threads
reading (or writing to) the same data should see a consistent picture
of the variable i.e. updates made to the common data should
immediately get reflected to other threads that are using it. However
I have never faced this issue in y multi-threaded code even though the
common variables are not declared volatile. So is this just a matter
of coincidence that I have had no runtime issues or is it that the
"volatile" keyword is required in some special situations that perhaps
my code does not encounter? I would love to know a demonstrable piece
of code that really shows the relevance of volatile variables in multi-
threaded environment.

volatile simply tells the compiler not to optimize out accesses to a
variable. It's very useful for things like memory-mapped hardware
registers.

Note that you can have a const volatile. One of my favorite
declarations from some real-life code I wrote was:

unsigned long const volatile * const HW_RDONLY_REG =
reinterpret_cas t<unsigned long const volatile *>(
0xC0008020);


Volatile does not guarantee asynchronous concurrent access consistency.

[gpderetta]

Re: use of keyword volatile in multi-threaded C++ program

On Sep 24, 7:22 am, Paul Pluzhnikov <ppluzhnikov-...@gmail.comwr ote:

"C++Liliput " <aveekmi...@gma il.comwrites:

It seems that the keyword "volatile" is used to make sure that threads
reading (or writing to) the same data should see a consistent picture
of the variable

>
[Your question is off-topic here, you should have asked it in
comp.programmin g.threads.]
>

Is it? Threading is in the draft standard and in a couple of years it
will be *the* standard. Aren't discussions about features present in
the upcoming standard on-topic here?

Such use of 'volatile' is always erroneous (or at a minimum
non-portable) -- volatile does *not* ensure "consistent picture of
the variable" on many common non-x86 machines.
>

In fact it doesn't even on x86 machines.

--
Giovanni P. Deretta

[James Kanze]

Re: use of keyword volatile in multi-threaded C++ program

On Sep 24, 12:50 pm, gpderetta <gpdere...@gmai l.comwrote:

On Sep 24, 7:22 am, Paul Pluzhnikov <ppluzhnikov-...@gmail.comwr ote:

"C++Liliput " <aveekmi...@gma il.comwrites:

It seems that the keyword "volatile" is used to make sure
that threads reading (or writing to) the same data should
see a consistent picture of the variable

[Your question is off-topic here, you should have asked it
in comp.programmin g.threads.]

Is it? Threading is in the draft standard and in a couple of
years it will be *the* standard. Aren't discussions about
features present in the upcoming standard on-topic here?

Even if it weren't part of the upcoming standard, it's part of
portable C++. More generally:

-- questions about precise details of the threading API of a
particular system belong in a group for that system,

-- general questions about threading (when to use it, how to
decide what goes into which thread, etc.) are probably more
appropriate in comp.programmin g.threads, but I wouldn't
really ban them here either, and

-- questions about the meaning of certain C++ keywords (like
volatile) in a threaded context are definitely on topic
here, and probably no where else.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34