[cpp-threads] RE: volatile, memory models, threads

[Boehm, Hans]

[Returning to this thread after several context switches ...]

The strawman proposal (revised after the C++ committee paper, and after
the beginning of this discussion) now states:

"We define an execution to contain an inter-thread race if two threads
perform two conflicting actions, neither happens-before the other, and
at least one is not a synchronization action."

Thus there is clearly a race here, as there was always intended to be.

Does that resolve all concerns?

Hans

> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk 
> [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf 
> Of Nick Maclaren
> Sent: Sunday, March 05, 2006 8:21 AM
> To: C++ threads standardisation
> Subject: Re: [cpp-threads] RE: volatile, memory models, threads
> 
> "Peter Dimov" <pdimov at mmltd.net> wrote:
> >
> > > The problem is that, if an object is accessed atomically via an 
> > > action A and non-atomically via an action B, then A must act as a 
> > > barrier to B, at all levels from the compiler down to the 
> hardware.
> > 
> > Do A and B occur in the same thread or in separate threads? If in 
> > separate threads, this doesn't impose any ordering and is a 
> data race 
> > and hence, undefined behavior, if at least one of the 
> actions is a write.
> 
> The same thread, for the reason you give.
> 
> > > Furthermore, there are gruesome gotchas with actions like the
> > > following:
> > >
> > > Thread 1:    X = 0x1200
> > >             *(atomic *)X = 0X0034
> > > Thread 2:    *(atomic *)X = 0X0045
> > >
> > > Is X allowed to end up as 0x1245?  If not, why not?
> > 
> > X should be allowed to end up as an arbitrary value; the program 
> > should also be allowed to die with a hardware exception. There is a 
> > data race between the 1200 and 0045 writes.
> 
> That is one viewpoint; there are others.  I am nailing my 
> colours to the fence, and don't give a damn as long as there 
> is a sane, clear specification.
> 
> > This is not what the strawman proposal says, though. It says that 
> > there is no race since at least one of the actions is a 
> > synchronization action. I'm not sure whether this is deliberate or 
> > accidental, and if deliberate, what is it supposed to accomplish.
> 
> Precisely.  That was my point.
> 
> 
> 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
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>