[cpp-threads] Slightly revised memory model proposal (D2300)

[Paul E. McKenney]

On Tue, Jun 05, 2007 at 08:31:43PM -0700, Hans Boehm wrote:
> 
> 
> On Tue, 5 Jun 2007, Nick Maclaren wrote:
> 
> >
> > As far as the MEMORY model goes, it doesn't make a huge difference
> > to C++ whether the primary thread is interrupted and a handler run
> > in the same thread, or whether another thread is being executed.
> > Both need comparable specifications of atomicity, synchronisation
> > etc.
> >
> Except of course that there are some major differences:
> 
> - Signal handlers can't normally use mechanisms like locks or barriers
> (in the OpenMP sense) to synchronize with the main thread, since it
> is implicitly stopped until the handler completes.

One must disable signals when acquiring locks, which is quite expensive
on many platforms.

> - Much cheaper mechanisms often suffice for enforcing memory visibility
> between a thread and a handler running in the same thread.  The hardware
> is usually no longer an issue; you only have to control compiler
> instruction reordering.

Agreed.

> I think there is an interesting question as to whether atomics should
> be usable for communicating with signal handlers, in at least the
> same sense that volatile sigatomic_t is now.  I have been assuming that
> this applies at most if the atomics are not emulated.  Otherwise the
> emulation would require disabling signals.  Opinions?

Agreed -- non-emulated atomics should be usable for communicating
with signal handlers.  Enforcing this for emulated atomics is as
you say quite expensive.

> BTW originally the "inter-thread data race" terminology came about because
> I had suggested dealing with undefined behavior caused by unsequenced
> accesses to an object by the same thread as "intra-thread data races".
> That ideas was effectively dropped.  So currently there is indeed no
> good reason for the terminology.

The clarification would still be nice, however.

							Thanx, Paul