[cpp-threads] Relaxed reload example

[Sarita V Adve]

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
>