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

Boehm, Hans hans.boehm at hp.com
Fri Mar 3 23:15:12 GMT 2006


The intent in the current model was that an inter-thread race occurs if
two conflicting actions are not happens-before ordered, and at least one
of them is not a synchronization action.  I just now fixed the strawman
proposal to make that clearer.  Sorry about that, and thanks for
pointing it out.

Thus the intent was to handle the case of objects being accessed
atomically and not atomically.  Whether there are any cases in which the
current model gives counter-intuitive semantics for such a case is less
clear to me.  After thinking about it a bit, I'm not sure there's a
problem.  If someone has tricky examples in mind, or suggestions for
improving the description of the memory model, please post.

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: Thursday, March 02, 2006 1:36 PM
> To: C++ threads standardisation
> Subject: Re: [cpp-threads] RE: volatile, memory models, threads
> 
> "Peter Dimov" <pdimov at mmltd.net> wrote:
> >
> > >> 2. making "atomic" a (non cv-) qualifier that can't be added 
> > >> implicitly, can be casted away relatively safely, and 
> can possibly 
> > >> be added via a cast relatively unsafely.
> > >
> > > The weakness of that is you then have to define ordering 
> semantics 
> > > between atomic and non-atomic accesses to the same object.  It 
> > > doesn't help if you forbid it, because you have to 
> defined WHAT you 
> > > are forbidding.
> > 
> > It seems to me that we have to define it in either case, because we 
> > want to allow races if
> > 
> > 1. both operations are reads
> > 2. both operations are atomics
> > 
> > and disallow everything else. So outlawing write+read and 
> write+write 
> > will automatically take care of atomic_write+read, 
> write+atomic_read, 
> > atomic_write+write.
> 
> Not if we use Hans Boehm's memory model.  The rules for how 
> accesses can be reordered are different for atomic and 
> non-atomic ones, but (as his paper standards at present), the 
> assumption is that the two are entirely distinct classes of 
> object.  It adds a considerable amount of complexity if they 
> can be the same.
> 
> 
> 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
> 



More information about the cpp-threads mailing list