🚀 go-pugleaf

X-Original-Date: 2 Jan 1996 07:22:26 GMT

I'm no expert but here is what I know.  The specifier volatile is 
a directive to the compiler that the variable declared volatile 
can change at any moment.  The compiler will then make no 
assumptions about the contents of this variable, and will always 
re-check its value when used.  An example of something that might 
use volatile variables is:  a hardware interface to your PC which 
reads analog data and converts it to digital.  Your program may 
read the data from the PC bus.  However this data is always 
changing and your program should make know assumptions that the 
data is the same - it should always recheck the value.

I'm sure there are other less complicated applications which may 
benefit from volatile variables.  I'm sure one of the many other 
experts on the net can elaborate.

-dnult@axiom.net


    [ comp.lang.c++.moderated is a moderated newsgroup.  Submit articles ]
    [  to <c++-submit@netlab.cs.rpi.edu>.  The moderation policy can be  ]
    [   retrieved from <http://netlab.cs.rpi.edu/~cppmods/guide.html>.   ]
    [    Moderators can be reached at: c++-request@netlab.cs.rpi.edu.    ]

X-Original-Date: 2 Jan 1996 15:47:59 GMT

Doesn't it also prevent the variable from being optimized away to a register?

scott


-- 
===========================================================================
 Scott Johnson                     
 web page:  http://rainbow.rmii.com/~iscottj/scott/scott.html  
 Check out the Colorado Internet Connection at: http://www.rmii.com/colocon  

    [ comp.lang.c++.moderated is a moderated newsgroup.  Submit articles ]
    [  to <c++-submit@netlab.cs.rpi.edu>.  The moderation policy can be  ]
    [   retrieved from <http://netlab.cs.rpi.edu/~cppmods/guide.html>.   ]
    [    Moderators can be reached at: c++-request@netlab.cs.rpi.edu.    ]

X-Original-Date: Tue, 02 Jan 1996 15:25:49 -0800

Srinivas Vobilisetti wrote:
> 
> X-Original-Date: 31 Dec 1995 01:42:27 GMT
> 
> Hello,
>

Concept of volatile can be easily using a simple example:

int a

a = 1;
a++
if (a==1) {
	...
}

typically compiler loads the value of variable a, into a register of a processor 
before executing 'a++'. and compares the value of register that holds the value 
instead of checking the value at the actual memory location. This optimization is default
in any C compiler. If suppose the location of variable a is a hardware location like
printer port, this optimization won't work, to supress such optimization we add the keyword
volatile, In that case compiler generate instruction to fetch from actual location instead
of fetching value from register.


 
> I referred to various books on C++ including The C++ Programming Language
> -Bjarne Stroustrup, C++ Primer -Stanley Lipmann, etc.  Nowhere i could find
> exact meaning of the specifier volatile. Thanks in advance for your help. I
> would appreciate the reply at my email address srv@cs.wayne.edu
> 
> Thanks
> Srinivas
> srv@cs.wayne.edu

    [ comp.lang.c++.moderated is a moderated newsgroup.  Submit articles ]
    [  to <c++-submit@netlab.cs.rpi.edu>.  The moderation policy can be  ]
    [   retrieved from <http://netlab.cs.rpi.edu/~cppmods/guide.html>.   ]
    [    Moderators can be reached at: c++-request@netlab.cs.rpi.edu.    ]

X-Original-Date: 3 Jan 1996 10:27:41 +0100

Srinivas Vobilisetti (srv@cs.wayne.edu) wrote:

|> I referred to various books on C++ including The C++ Programming Language
|> -Bjarne Stroustrup, C++ Primer -Stanley Lipmann, etc.  Nowhere i could find
|> exact meaning of the specifier volatile. Thanks in advance for your help. I
|> would appreciate the reply at my email address srv@cs.wayne.edu

According to the ARM, volatile has no portable meaning; the precise
meaning is implementation defined.  In fact, there are a few odd
guarantees in the standard: in particular, reads and writes of a
volatile are considered part of the observable behavior of a program.
There is also a statement to the effect that the value of a volatile
object may change in ways unknown to the compiler.

What this means in practice is that the compiler should turn off
optimization of volatile variables; the program should do exactly what
you wrote, no more, no less.  Note that there is no such guarantee with
regards to other variables; the only guarantee is that the observable
behavior be "as if" the program does what you wrote.

Volatile variables are normally used precisely where things are going on
"outside of the program".  The classical example is a (memory-mapped)
real time clock; if the variable were not declared volatile, a good
compiler might detect that it was never written, and save the first
value read somewhere in a register.  Declared volatile, the compiler
must read it every time you write an expression which accesses it.

What this means exactly *IS* somewhat implementation dependant.  When
using volatile objects, you should generally eschew complex expressions,
particularly those which access the object twice in the same expression,
and read the documentation for your implementation very carefully, as to
how volatile is interpreted exactly.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone

    [ comp.lang.c++.moderated is a moderated newsgroup.  Submit articles ]
    [  to <c++-submit@netlab.cs.rpi.edu>.  The moderation policy can be  ]
    [   retrieved from <http://netlab.cs.rpi.edu/~cppmods/guide.html>.   ]
    [    Moderators can be reached at: c++-request@netlab.cs.rpi.edu.    ]

X-Original-Date: 03 Jan 1996 14:10:13 GMT

In article <4cb5i3$5mr@netlab.cs.rpi.edu> Dave Nulton <dnult@axiom.net> writes:

   I'm no expert but here is what I know.  The specifier volatile is 
   a directive to the compiler that the variable declared volatile 
   can change at any moment.  The compiler will then make no 
   assumptions about the contents of this variable, and will always 
   re-check its value when used.  An example of something that might 
   use volatile variables is:  a hardware interface to your PC which 
   reads analog data and converts it to digital.  Your program may 
   read the data from the PC bus.  However this data is always 
   changing and your program should make know assumptions that the 
   data is the same - it should always recheck the value.

I believe volatile directs the compiler to not optimize the variable
as the value can change w/o the compiler being aware.  The compiler
will not "always recheck the value", but will do exactly what you
coded -- nothing more, nothing less.  It is up to the programmer to
appropriately access this value.  A classic example is accessing such
a value inside a loop, where normal optimization might pull that
access outside the loop.  Volatile can prevent this.

>From the ARM:  "volatile is a hint to the compiler to avoid aggressive
optimization involving the object because the value of the object may
be changed by means undetectable by a compiler."

My $0.02.
Brian

   I'm sure there are other less complicated applications which may 
   benefit from volatile variables.  I'm sure one of the many other 
   experts on the net can elaborate.

   -dnult@axiom.net
-- 

+---------------------------+----------------------------------+
| Brian Thorstad            | Data General Corporation         |
|  (thorstad@dg-rtp.dg.com) |                                  |
| Voice: (919) 248-6062     | 62 T.W. Alexander Dr.            |
| Fax:   (919) 248-6108     | Research Triangle Park, NC 27709 |
+---------------------------+----------------------------------+

    [ comp.lang.c++.moderated is a moderated newsgroup.  Submit articles ]
    [  to <c++-submit@netlab.cs.rpi.edu>.  The moderation policy can be  ]
    [   retrieved from <http://netlab.cs.rpi.edu/~cppmods/guide.html>.   ]
    [    Moderators can be reached at: c++-request@netlab.cs.rpi.edu.    ]

X-Original-Date: 03 Jan 1996 19:38:59 GMT

In article <4c9740$27n@netlab.cs.rpi.edu> Srinivas Vobilisetti
<srv@cs.wayne.edu> writes:

   Nowhere i could find exact meaning of the specifier volatile.

Consider the following piece of code:

int n;
for (int i=0; i<99; i++)
  n=0;

A good optimising compiler should rewrite this as:

int n=0;
int i=100;

{That's right, if you want to delay for 100 micro seconds, the above
is not a portable approach.}

The use of the keyword volatile prevents the compiler from optimising
the reads and writes to a variable.  

volatile int n;
for (int i=0; i<99; i++)
  n=0;

Will cause zero to be written into the variable n 100 times. 
{Note, the compiler may be smart enough to do this without using the
variable i!}.

volatile int n;
for (volatile int i=0; i<99; i++)
  n=0;

Will cause zero to be written into the variable n 100 times.  It will
also cause the variable i to be incremented inbetween writes to n, and
will read i to test it for 99 each time through the loop.

Generally, this is used when certain memory registers have side
effects.  e.g.

int * volatile tty = 0x100;  // 0x100 is the addr of the tty device.

*tty = 'h'; // prints a 'c' on the tty;

void PrintMessage(char *s)
{
  for(; *s; s++) *tty = *s; // prints the string on the tty.
}

You can also use volatile if you want to create stupid delays as in
the first example.

--
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@oma.com     |   OOA/D, C++, Advanced OO
14619 N. Somerset Cr| Tel: (708) 918-1004 |   Mgt. Overview of OOT
Green Oaks IL 60048 | Fax: (708) 918-1023 | Development Contracts.


    [ comp.lang.c++.moderated is a moderated newsgroup.  Submit articles ]
    [  to <c++-submit@netlab.cs.rpi.edu>.  The moderation policy can be  ]
    [   retrieved from <http://netlab.cs.rpi.edu/~cppmods/guide.html>.   ]
    [    Moderators can be reached at: c++-request@netlab.cs.rpi.edu.    ]

X-Original-Date: Thu, 04 Jan 1996 11:47:04 +0200

Srinivas Vobilisetti (srv@cs.wayne.edu) wrote:

|> I referred to various books on C++ including The C++ 
Programming Language
|> -Bjarne Stroustrup, C++ Primer -Stanley Lipmann, etc.  
Nowhere i could find
|> exact meaning of the specifier volatile. Thanks in advance 
for your help.

As told in many replies, volatile specifies that the 
variable's contents can change between its use in the program. 
However, volatile allows you to add another level of checking, 
too. For instance, if you know that your program should never 
change the variable's contents (eg. a memory location for a 
real-time clock value), you can use const volatile. Thus, the 
compiler will check at compile time that your program will not 
modify itself the value, but will prevent optimization of 
using the value once read.

 Ari Lukumies


-- 
All my opinions are mine and mine alone.

    [ comp.lang.c++.moderated is a moderated newsgroup.  Submit articles ]
    [  to <c++-submit@netlab.cs.rpi.edu>.  The moderation policy can be  ]
    [   retrieved from <http://netlab.cs.rpi.edu/~cppmods/guide.html>.   ]
    [    Moderators can be reached at: c++-request@netlab.cs.rpi.edu.    ]

X-Original-Date: Thu, 04 Jan 1996 16:09:37 +0100

In article (Dans l'article) <4cff74$gfj@netlab.cs.rpi.edu>,
rmartin@oma.com (Robert C. Martin) wrote (=E9crivait)=A0:

<Snip>

>int * volatile tty =3D 0x100;  // 0x100 is the addr of the tty device.
>
>*tty =3D 'h'; // prints a 'c' on the tty;
>
>void PrintMessage(char *s)
>{
>  for(; *s; s++) *tty =3D *s; // prints the string on the tty.
>}
>

I would have written

volatile int * tty =3D 0x100;  // 0x100 is the addr of the tty device.

instead. The meaning is *not* the same.
--=20
Dominique Bernardi, Theorie des Nombres
Universite Pierre et Marie Curie
4 place Jussieu - F75005 Paris Tel (33-1) 44275441
bernardi@mathp6.jussieu.fr

    [ comp.lang.c++.moderated is a moderated newsgroup.  Submit articles ]
    [  to <c++-submit@netlab.cs.rpi.edu>.  The moderation policy can be  ]
    [   retrieved from <http://netlab.cs.rpi.edu/~cppmods/guide.html>.   ]
    [    Moderators can be reached at: c++-request@netlab.cs.rpi.edu.    ]

X-Original-Date: 3 Jan 1996 20:28:51 GMT

volatile is used to identify a variable that might be changed by something other
than one of your programs.  a use for this might be a piece of hardware that
collects real-time data, or statistics about heat/tempature, and the volatile
variable is the link between your program and the hardware stuff.


Matt Dean
dean@KnK.com
dean@digital.net 

    [ comp.lang.c++.moderated is a moderated newsgroup.  Submit articles ]
    [  to <c++-submit@netlab.cs.rpi.edu>.  The moderation policy can be  ]
    [   retrieved from <http://netlab.cs.rpi.edu/~cppmods/guide.html>.   ]
    [    Moderators can be reached at: c++-request@netlab.cs.rpi.edu.    ]

X-Original-Date: Fri, 05 Jan 96 06:16:22 GMT

In article <4cb5i3$5mr@netlab.cs.rpi.edu>,
   Dave Nulton <dnult@axiom.net> wrote:
>Path: news.interlog.com!winternet.com!uunet!in1.uu.net!news.mathworks.com!news.kei.com!ub!library.erc.clarkson.edu!rpi!not-for-mail
>From: Dave Nulton <dnult@axiom.net>
>Newsgroups: comp.lang.c++.moderated,comp.lang.c++
>Subject: Re: Meaning of the specifier volatile?
>Date: 2 Jan 1996 11:39:47 -0000
>Organization: Axiom Communications
>Lines: 24
>Sender: cppmods@netlab.cs.rpi.edu
>Approved: kanze@gabi-soft.fr
>Message-ID: <4cb5i3$5mr@netlab.cs.rpi.edu>
>References: <4c9740$27n@netlab.cs.rpi.edu>
>NNTP-Posting-Host: netlab.cs.rpi.edu
>Xref: news.interlog.com comp.lang.c++.moderated:518 comp.lang.c++:166027
>Status: N
>
>X-Original-Date: 2 Jan 1996 07:22:26 GMT
>
>I'm no expert but here is what I know.  The specifier volatile is 
>a directive to the compiler that the variable declared volatile 
>can change at any moment.  The compiler will then make no 
>assumptions about the contents of this variable, and will always 
>re-check its value when used.  An example of something that might 
>use volatile variables is:  a hardware interface to your PC which 
>reads analog data and converts it to digital.  Your program may 
>read the data from the PC bus.  However this data is always 
>changing and your program should make know assumptions that the 
>data is the same - it should always recheck the value.
>
>I'm sure there are other less complicated applications which may 
>benefit from volatile variables.  I'm sure one of the many other 
>experts on the net can elaborate.
>
>-dnult@axiom.net
>
>
>    [ comp.lang.c++.moderated is a moderated newsgroup.  Submit articles ]
>    [  to <c++-submit@netlab.cs.rpi.edu>.  The moderation policy can be  ]
>    [   retrieved from <http://netlab.cs.rpi.edu/~cppmods/guide.html>.   ]
>    [    Moderators can be reached at: c++-request@netlab.cs.rpi.edu.    ]


"volatile" can be handy in a multi-threaded program too.  Suppose you've got a flag that
will be set in one thread to indicate that another thread can now proceed.  The flag needs
to be marked as "volatile" because its value will magically change through an external 
source (i.e. the other thread).  Without the "volatile" keyword, an optimizing compiler is probably 
going to assume that the value of the flag can't change (resulting in an infinite loop -- not that 
this has ever happened to me).

that is waiting for the flag to be set, the The thread
that is waiting that indicates that another thread can 

    [ comp.lang.c++.moderated is a moderated newsgroup.  Submit articles ]
    [  to <c++-submit@netlab.cs.rpi.edu>.  The moderation policy can be  ]
    [   retrieved from <http://netlab.cs.rpi.edu/~cppmods/guide.html>.   ]
    [    Moderators can be reached at: c++-request@netlab.cs.rpi.edu.    ]

X-Original-Date: 5 Jan 1996 03:38:08 GMT

In article <4c9740$27n@netlab.cs.rpi.edu>,
Srinivas Vobilisetti  <srv@cs.wayne.edu> wrote:
>X-Original-Date: 31 Dec 1995 01:42:27 GMT
>
>Hello,
>
>I referred to various books on C++ including The C++ Programming Language
>-Bjarne Stroustrup, C++ Primer -Stanley Lipmann, etc.  Nowhere i could find
>exact meaning of the specifier volatile. Thanks in advance for your help. I
>would appreciate the reply at my email address srv@cs.wayne.edu
>
>Thanks
>Srinivas
>srv@cs.wayne.edu

Basically the specifier 'volatile' means that the variable or object
may be corrupted by some external sources, e.g. hardware interrupt.
For example, you can write
	volative const int some_int;
which means some_int may be changed by some external "powers", but not
your program.

Hope this will help

Handong Wang
Department of Computer Science
Univ. of Western Ontario
London Ontario 
Canada
-- 
Handong Wang
Department of Computer Science
University of Western Ontario
London, Ontario Canada

    [ comp.lang.c++.moderated is a moderated newsgroup.  Submit articles ]
    [  to <c++-submit@netlab.cs.rpi.edu>.  The moderation policy can be  ]
    [   retrieved from <http://netlab.cs.rpi.edu/~cppmods/guide.html>.   ]
    [    Moderators can be reached at: c++-request@netlab.cs.rpi.edu.    ]

X-Original-Date: 5 Jan 1996 10:40:05 +0100

Robert C. Martin (rmartin@oma.com) wrote:

|> In article <4c9740$27n@netlab.cs.rpi.edu> Srinivas Vobilisetti
|> <srv@cs.wayne.edu> writes:

|>    Nowhere i could find exact meaning of the specifier volatile.

|> Consider the following piece of code:

|> int n;
|> for (int i=0; i<99; i++)
|>   n=0;

|> A good optimising compiler should rewrite this as:

|> int n=0;
|> int i=100;

|> {That's right, if you want to delay for 100 micro seconds, the above
|> is not a portable approach.}

|> The use of the keyword volatile prevents the compiler from optimising
|> the reads and writes to a variable.  

|> volatile int n;
|> for (int i=0; i<99; i++)
|>   n=0;

|> Will cause zero to be written into the variable n 100 times. 
|> {Note, the compiler may be smart enough to do this without using the
|> variable i!}.

|> volatile int n;
|> for (volatile int i=0; i<99; i++)
|>   n=0;

|> Will cause zero to be written into the variable n 100 times.  It will
|> also cause the variable i to be incremented inbetween writes to n, and
|> will read i to test it for 99 each time through the loop.

Note, of course, that the exact meaning of operator ++ on a volatile
object is somewhat open to discussion.  For example, on a machine with a
hardware increment instruction, the compiler might increment `i' in
memory, *THEN* read it into a register, decrement the value and use it.
This may result in the value being read twice.

If the object in question is a normal memory object, and you are not
concerned with asynchronous events (signals, asynchronous thread
changes), this is probably not a problem.  If the object in question is
a memory mapped IO port, where a read has a side effect, this may be a
disaster.

As a general rule, the only things I would try to do with a volatile
object are to read them and write them directly, and not in the same
expression.  If I really had to increment a volatile int, I would
generally use three statements: tmp = i ; tmp ++ ; i = tmp ;.  (Of
course, since anything like this will be unportable by definition, I
would read the compiler documentation to see exactly how the compiler
treated volatile.)

|> Generally, this is used when certain memory registers have side
|> effects.  e.g.

|> int * volatile tty = 0x100;  // 0x100 is the addr of the tty device.
                        ^^^^^

This shouldn't work without an explicit cast, should it?

|> *tty = 'h'; // prints a 'c' on the tty;

|> void PrintMessage(char *s)
|> {
|>   for(; *s; s++) *tty = *s; // prints the string on the tty.
|> }

|> You can also use volatile if you want to create stupid delays as in
|> the first example.

Except that the length of the delay would still be undefined, since the
compiler can insert any additional code it likes into the loop.

On point concerning volatile that I have not seen made is the fact that
the C/C++ concept of volatile is orthogonal to atomicity of access.
Declaring an object volatile is *NOT* sufficient with regards to
asynchronous events; the object must still be of a type for which the
compiler will generate atomic accesses.  In general, char, short, and
int are safe, although there are exceptions.  (On 8 bit machines,
generally only char will be safe, and on the TI 9900 (and probably some
word addressed machines), int will be safe, but not char.)

In portable code, all you can count on is that at least one integral
type will be safe; that type is defined by a typedef to sig_atomic_t in
signal.h.  So in practice, there is almost nothing portable that you can
do in the presence of asynchronous events.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone

    [ comp.lang.c++.moderated is a moderated newsgroup.  Submit articles ]
    [  to <c++-submit@netlab.cs.rpi.edu>.  The moderation policy can be  ]
    [   retrieved from <http://netlab.cs.rpi.edu/~cppmods/guide.html>.   ]
    [    Moderators can be reached at: c++-request@netlab.cs.rpi.edu.    ]

X-Original-Date: 6 Jan 1996 21:57:16 GMT

J. Kanze (kanze@gabi-soft.fr) wrote:
[stuff deleted]
: On point concerning volatile that I have not seen made is the fact that
: the C/C++ concept of volatile is orthogonal to atomicity of access.
: Declaring an object volatile is *NOT* sufficient with regards to
: asynchronous events; the object must still be of a type for which the
: compiler will generate atomic accesses.  
[stuff deleted]

Because of the signal-handlers-can't-read provision of the ANSI C
standard, atomicity is unnecessary in the coordination of asynchronous
activity for programs with defined behavior:

  *  signal handlers won't read any partially written non-atomic 
     shared variables, because they are not allowed to read variables 
     of static storage class in programs with defined behavior.

  *  the program itself won't read any partially written non-atomic 
     shared varible, because signal handlers don't return control 
     until they have completed their writes of volatile variables.

With pre-emptive multithreading, of course, the possibility of
pre-emption during a non-atomic write requires atomicity of some
coordination variables, but it's impossible to introduce
multithreading and stay within defined behavior per the ANSI 
standard.

Tom Payne (thp@cs.ucr.edu)

    [ comp.lang.c++.moderated is a moderated newsgroup.  Submit articles ]
    [  to <c++-submit@netlab.cs.rpi.edu>.  The moderation policy can be  ]
    [   retrieved from <http://netlab.cs.rpi.edu/~cppmods/guide.html>.   ]
    [    Moderators can be reached at: c++-request@netlab.cs.rpi.edu.    ]

X-Original-Date: 11 Jan 1996 12:45:44 +0100

Tom Payne (thp@cs.ucr.edu) wrote:

|> J. Kanze (kanze@gabi-soft.fr) wrote:
|> [stuff deleted]
|> : On point concerning volatile that I have not seen made is the fact that
|> : the C/C++ concept of volatile is orthogonal to atomicity of access.
|> : Declaring an object volatile is *NOT* sufficient with regards to
|> : asynchronous events; the object must still be of a type for which the
|> : compiler will generate atomic accesses.  
|> [stuff deleted]

|> Because of the signal-handlers-can't-read provision of the ANSI C
|> standard, atomicity is unnecessary in the coordination of asynchronous
|> activity for programs with defined behavior:

|>   *  signal handlers won't read any partially written non-atomic 
|>      shared variables, because they are not allowed to read variables 
|>      of static storage class in programs with defined behavior.

|>   *  the program itself won't read any partially written non-atomic 
|>      shared varible, because signal handlers don't return control 
|>      until they have completed their writes of volatile variables.

Close.  The program itself won't read any partially written non-atomic
shared variables, because signal handlers are not allowed to write such
variables in programs with defined behavior.

Note that your statement, if allowed, could lead to anomalies if a
non-atomic read is interrupted, and the signal handler writes the
object.  The first part of the read sees the old value, and the second
part the new value.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone

    [ comp.lang.c++.moderated is a moderated newsgroup.  Submit articles ]
    [  to <c++-submit@netlab.cs.rpi.edu>.  The moderation policy can be  ]
    [   retrieved from <http://netlab.cs.rpi.edu/~cppmods/guide.html>.   ]
    [    Moderators can be reached at: c++-request@netlab.cs.rpi.edu.    ]

X-Original-Date: 6 Jan 1996 21:57:16 GMT
[moderator's note:  This posting was apparently lost or delayed somewhere in the
'net, and we am re-posting it.  Please bear with us if this is a duplicate.]
J. Kanze (kanze@gabi-soft.fr) wrote:
[stuff deleted]
: On point concerning volatile that I have not seen made is the fact that
: the C/C++ concept of volatile is orthogonal to atomicity of access.
: Declaring an object volatile is *NOT* sufficient with regards to
: asynchronous events; the object must still be of a type for which the
: compiler will generate atomic accesses.  
[stuff deleted]

Because of the signal-handlers-can't-read provision of the ANSI C
standard, atomicity is unnecessary in the coordination of asynchronous
activity for programs with defined behavior:

  *  signal handlers won't read any partially written non-atomic 
     shared variables, because they are not allowed to read variables 
     of static storage class in programs with defined behavior.

  *  the program itself won't read any partially written non-atomic 
     shared varible, because signal handlers don't return control 
     until they have completed their writes of volatile variables.

With pre-emptive multithreading, of course, the possibility of
pre-emption during a non-atomic write requires atomicity of some
coordination variables, but it's impossible to introduce
multithreading and stay within defined behavior per the ANSI 
standard.

Tom Payne (thp@cs.ucr.edu)

    [ comp.lang.c++.moderated is a moderated newsgroup.  Submit articles ]
    [  to <c++-submit@netlab.cs.rpi.edu>.  The moderation policy can be  ]
    [   retrieved from <http://netlab.cs.rpi.edu/~cppmods/guide.html>.   ]
    [    Moderators can be reached at: c++-request@netlab.cs.rpi.edu.    ]

J. Kanze (kanze@gabi-soft.fr) wrote:
: X-Original-Date: 11 Jan 1996 12:45:44 +0100
: 
: Tom Payne (thp@cs.ucr.edu) wrote:
: 
: |> J. Kanze (kanze@gabi-soft.fr) wrote:
: |> [stuff deleted]
: |> : On point concerning volatile that I have not seen made is the fact that
: |> : the C/C++ concept of volatile is orthogonal to atomicity of access.
: |> : Declaring an object volatile is *NOT* sufficient with regards to
: |> : asynchronous events; the object must still be of a type for which the
: |> : compiler will generate atomic accesses.  
: |> [stuff deleted]
: 
: |> Because of the signal-handlers-can't-read provision of the ANSI C
: |> standard, atomicity is unnecessary in the coordination of asynchronous
: |> activity for programs with defined behavior:
: 
: |>   *  signal handlers won't read any partially written non-atomic 
: |>      shared variables, because they are not allowed to read variables 
: |>      of static storage class in programs with defined behavior.
: 
: |>   *  the program itself won't read any partially written non-atomic 
: |>      shared varible, because signal handlers don't return control 
: |>      until they have completed their writes of volatile variables.
[...]
: Note that your statement, if allowed, could lead to anomalies if a
: non-atomic read is interrupted, and the signal handler writes the
: object.  The first part of the read sees the old value, and the second
: part the new value.


Oops -- I stand corrected!  The de facto atomicity of access by
*uninterrupted* signal handlers doesn't cover all cases.

Tom Payne (thp@cs.ucr.edu)


      [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
      [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
      [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
      [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]