🚀 go-pugleaf

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       ]