🚀 go-pugleaf

Dick Menninger (Dick.Menninger@daytonoh.attgis.com) wrote:
: > ==========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).

Agreed: the need to block concurrent access to shared data is often
inevitable.  To lock out standard threads during such a critical
section, one acquires a lock.  To lock out signal-sustained
pseudothreads, one blocks the corresponding signals.  It is a defining
characteristic of threads, however, that they can wait.

Tom Payne

[Moderator's note: this is a valuable discussion, but it's beginning to
drift away from C++ standardization.  I suggest continuing it in
comp.compilers.  mha]

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