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

[Hans Boehm]

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.

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

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?

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.

Hans