🚀 go-pugleaf

J. Kanze (kanze@gabi.gabi-soft.fr) wrote:
: In article <4ebptg$frt@galaxy.ucr.edu> thp@cs.ucr.edu (Tom Payne)
: writes:
: 
: > : From ISO 9899, section 7.7.1.1: ``If the signal occurs other than as the
: > : result of calling the abort or raise function, the behavior is undefined
: > : if the signal handler calls any function in the standard library other
: > : than the signal function itself (with a first argument of the signal
: > : number corresponding to the signal tha caused the invocation of the
: > : handler) or refers to any object with static storage duration other than
: > : by assigning a value to a static storage duration variable of type
: > : volatile sig_atomic_t.''
: > [...]
: > 
: > In other words, the only asynchronous activity allowed to programs
: > with defined behavior is polling volatile atomic variables that are
: > set by signal handlers.  Thus far, no one has given me a reason for
: > prohibiting signal handlers from reading volatile atomic variables,
: > which is a common practice in interrupt handlers (even those written
: > in C/C++).
: 
: Correct.  In practice, I cannot conceive of an implementation where
: writing something would be atomic, but reading it wouldn't.  On the
: other hand, read/modify/write will frequently not be atomic.  And why
: else might you want to read an object in a signal handler, if not to
: modify it?

Atomicity of such updates to atomic variables is not always a problem.
For instance, in most cases a signal handler can increment an atomic
counter (e.g. a timer) without difficulties, even though the
read/modify/write sequence is not atomic.  In the case of nonatomic
variables, atomicity must be enforced by blocking certain signals.
Such blockage could be portably implemented via atomic blockage flags,
which, in turn, are volatile atomic variables that must be read by
signal handers.

Tom Payne  (thp@cs.ucr.edu)

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  summarized in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
]