[cpp-threads] Relaxed reload example

[Paul E. McKenney]

Hello, Sarita,

That is indeed very similar to the explanation I got from the Alpha
architects.  It took them some time to convince me that their hardware
would really do such a thing.  It then took me even longer to convince
them that no sane x86 programmer would conclude that from reading the
Alpha architecture manual.  ;-)

							Thanx, Paul

On Wed, Aug 01, 2007 at 09:20:30PM -0500, Sarita V Adve wrote:
> Another way this could happen in hardware is if the release barriers
> only ensure that invalidations are posted at other processors and
> acquire side barriers ensure that all posted invalidates actually affect
> their processor's cache. Then the said outcome can occur if the
> dereferenced address is cached and the invalidation isn't yet applied to
> the cached copy (because there is no memory barrier). There is no
> speculation here.
> 
> Sarita
> 
> > -----Original Message-----
> > From: cpp-threads-bounces at decadentplace.org.uk 
> > [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf 
> > Of Paul E. McKenney
> > Sent: Wednesday, August 01, 2007 7:20 PM
> > To: Herb Sutter
> > Cc: C++ threads standardisation
> > Subject: Re: [cpp-threads] Relaxed reload example
> > 
> > On Wed, Aug 01, 2007 at 03:16:49PM -0700, Herb Sutter wrote:
> > > > DEC Alpha would in fact permit this outcome.
> > > 
> > > Why doesn't that surprise me? :-)
> > 
> > ;-)
> > 
> > > > I am not aware of any other CPU that permits this outcome.
> > > 
> > > I was more specifically wondering what the draft C++MM said 
> > about it. At
> > > least one subquestion would be whether relaxed reads can be 
> > replicated
> > > (by the CPU, or the compiler, etc.). Not sure if there are 
> > other ways
> > > the result could happen.
> > 
> > The current C++MM does in fact allow this outcome.  N2260 proposes
> > adding mechanism that permits the programmer to disallow this outcome
> > without incurring the overhead of an explicit fence.  There will be a
> > new version of this document soon.
> > 
> > This outcome could happen on non-Alpha platforms via value speculation
> > and other similar compiler optimizations.  The order of events might
> > be as follows:
> > 
> > T1.	Correctly guess the value of the not-yet-assigned pointer.
> > 
> > T1.	Dereference the guess, pick up uninitialized fields from the
> > 	structure.
> > 
> > T2.	Initialize the fields in the structure.
> > 
> > T2.	Store-release the pointer to the new structure.
> > 
> > T1.	Validate the guessed value for the pointer.  Since they
> > 	match, incorrectly conclude that the dereference operation
> > 	went smoothly.
> > 
> > Can't say that I am a fan of such optimizations, but others disagree.
> > 
> > 						Thanx, Paul
> > 
> > -- 
> > cpp-threads mailing list
> > cpp-threads at decadentplace.org.uk
> > http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
> >