🚀 go-pugleaf

> ==========Tom Payne, 2/4/96==========

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

Although that could keep them from reading a bad value,
they have no way to wait for it to become valid if they
interrupted the owner. So, the updater thread would have
to fully block the signals that really need the value in the
handler for handling to proceed.  That is, the problems
are more severe than between threads that do not interrupt
each other (a signal handler is just a specialized thread,
whether or not the environment's terminology calls it that
is irrelevant).

Good Day
Dick
Dick.Menninger@DaytonOH.ATTGIS.COM
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]