🚀 go-pugleaf

Dick Menninger (Dick.Menninger@daytonoh.attgis.com) wrote:
: > ==========Tom Payne, 2/4/96==========
: > 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).

The issues are the same as in any concurrent programming: 

  You've got protect critical data with locks, and you must block 
  an interrupt (signal) whenever you hold a lock that its handler 
  might attempt to acquire.

The locks and blockage mechanisms must be atomic, but not the data
they protect (which de-facto is subject to atomic access only).

Atomicity issues aside, the multithreaded context is probably the
correct one in which to consider the semantics for exceptions thrown
by signal handlers.  For instance, which thread should catch such an
exception?  The interrupted thread is sort of a hapless victim, and
there's no reason to expect it to be prepared to handle the exception.
If we let the throwing handler designate the catcher, we have a form
of pre-emptive message passing, where the message-receiver function
rethrows the exception in the context of the cathcher thread.  This
may make some of the problems easier, if the invocation of the
receiver can be made to occurr at conventient times, e.g., when the
stack is tidy.

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