[cpp-threads] Web site updated

[Paul E. McKenney]

On Wed, Feb 14, 2007 at 12:46:38AM +0200, Peter Dimov wrote:
> Paul E. McKenney wrote:
> >On Tue, Feb 13, 2007 at 09:56:06PM +0200, Peter Dimov wrote:
> >>Paul E. McKenney wrote:
> >>
> >>>>Similarly, I'd expect in
> >>>>
> >>>>a.store_raw( 5 );
> >>>>a.store_raw( 6 );
> >>>>
> >>>>the first store to be optimized out.
> >>>
> >>>MMIO accesses, anyone?
> >>
> >>This is what volatile is for.
> >
> >To the extent that it is defined...
> 
> Well. We routinely get arguments about how undefined volatile is, but 
> nobody seems to have any problems with it in practice. Compiler writers and 
> users tend to agree on its basic effects (extensions to provide 
> acquire/release constraints notwithstanding.) There are some complications 
> in C++ having to do with the lvalue to rvalue conversion, but no real 
> showstoppers. :-)

Looks like a list of the problems to me.

> >>>Hardware timing analysis (especially if there is a short loop
> >>>between the two)?
> >>
> >>(1) A short loop composed of ordinary operations can be reordered
> >>across either store;
> >
> >Even though it is a special store_raw()?
> 
> What is "special store_raw"? The difference between store_raw (or _relaxed) 
> and store_release is that store_relaxed is missing the reordering 
> constraint. The only sensible reason to omit a reordering constraint is to 
> enable reordering. So
> 
> // ordinary ops
> store_relaxed
> 
> can be transformed to
> 
> // ordinary ops 1/2
> store_relaxed
> // ordinary ops 2/2
> 
> (by the compiler or the hardware) but
> 
> // ordinary ops
> store_release
> 
> cannot.

The compiler's and the hardware's reordering is almost, but not quite,
equivalent.  The hardware is constrained so that a given CPU refrains
from doing any reordering that would be visible to that CPU.  In contrast,
the compiler's reordering can be visible even within the confines of a
single CPU, for example, via signal handlers (or, equivalently, interrupt
handlers).

> >This would prohibit implementations of reference counts or locks based on 
> >store_raw().
> 
> I believe that reference counts do work when the increment is _relaxed. 
> Unlocking a mutex is a _release operation, so I'm not sure how store_raw is 
> relevant there. But I may be missing something.

Interactions with signal/interrupt handlers.

							Thanx, Paul