[cpp-threads] modes, interlude

[Boehm, Hans]

To be fair, there are probably different degrees of "totally busted"
here :-).  I don't think read_barrier_depends() is specifiable in a
language
standard.  For the Linux kernel, I think there's also a risk, but
so long as it's only used in simple cases, it might be OK.  If it
does break, because some clever optimization breaks the dependency,
you fix that particular case by hand (though it would
be a real pain to track down).  In a language standard we can't
really say "use this only in simple cases".

Having said that, I recently did add something similar to atomic_ops,
and I believe less and less that it belongs there.

Hans

> -----Original Message-----
> From: 
> Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk 
> [mailto:Cpp-threads_decadentplace.org.uk-bounces at decadentplace
> .org.uk] On Behalf Of Alexander Terekhov
> Sent: Tuesday, May 10, 2005 6:22 AM
> To: cpp-threads at decadentplace.org.uk
> Subject: Re: [cpp-threads] modes, interlude
> 
> 
> On 5/10/05, Peter Dimov <pdimov at mmltd.net> wrote:
> 
> [... breaking dd* ...]
> 
> > and break the data dependency. We could disallow this optimization 
> > when ddacq is present, but to do that, we need to define whether an 
> > expression is data-dependent. :-)
> 
> How fascinating. So read_barrier_depends() stuff in Linux (e.g
> http://oss.sgi.com/projects/netdev/archive/2004-07/msg00375.html)
> is also totally busted. (Just like refcounting, etc. ;-) )
> 
> regards,
> alexander.
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk 
> http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decad
entplace.org.uk