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

[Nick Maclaren]

"Beman Dawes" <bdawes at acm.org> wrote:
>
> Are you saying that there should be an "interrupt data race" defined in
> addition to "inter-thread data race", and then "data race" defined as
> either an interrupt data race or an inter-thread data race?

I hope that the same definition would be applicable to both.

> (Sorry to be so dense about this, but I've never run into the concept
> of an interrupt data race before. However, I do think the standard
> needs to be clear about this, even to people like me.)

There's a reason for that - it's a foully arcane area, and is rarely
described in terms like that.  But, yes, it's important.  However,
from a C++ point of view, it can be simplified down to defining
atomicity and what an object is - yes, my old POD issue :-(

The reason is that the subtleties of interrupt data races are very
important to people who write low-level handlers, but it is reasonable
to say that the main thread of control should have been quiesced
before the interrupt handler gets control, and conversely on return.

What CAN'T be hidden is such things as a store being half-completed
when it is interrupted.  Hence the atomicity and POD issues.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679