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

[Beman Dawes]

On 6/5/07, Paul E. McKenney <paulmck at linux.vnet.ibm.com> wrote:
>
> On Mon, Jun 04, 2007 at 10:27:03PM -0400, Beman Dawes wrote:
> > On 6/4/07, Boehm, Hans <hans.boehm at hp.com> wrote:
> > >
> > >Attached is an early draft of a document with just the threads changes
> > >from N2171, adjusted a little as a result of feedback from Paul and
> > >others.
> >
> >
> > * I believe this paper should change 15.3, Handling an exception,
> paragraph
> > 9, as indicated:
> >
> > If no matching handler is found in a program *the current thread of
> > execution*, the function std::terminate() is called; whether or not the
> > stack is unwound before this call to std::terminate() is
> > implementation-defined (15.5.1).
> >
> > * The proposal uses the terms "data race" and "inter-thread data race"
> > apparently to mean the same thing. It seems to me only "data race"
> should be
> > used - it is confusing to talk about inter-thread data races because the
> > qualification implies there is some other kind of data race, yet no
> other
> > kind of data race is described.
>
> In the case of a type that cannot be loaded or stored atomically, one
> could talk about the race between accessing the type from the mainline
> and from a signal/interrupt handler.


 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?

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

--Beman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.decadentplace.org.uk/pipermail/cpp-threads/attachments/20070605/fec269d6/attachment.html