[cpp-threads] Web site updated

[Paul E. McKenney]

On Fri, Feb 16, 2007 at 05:36:32AM +0200, Peter Dimov wrote:
> Paul E. McKenney wrote:
> 
> >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).
> 
> Maybe, but there is still need for a _relaxed atomic which does not 
> prohibit reorderings, and for a _release atomic which only prohibits 
> reorderings in the downward direction.

On _relaxed, I agree completely.  I am still a bit uncomfortable with
_acquire/_release, but I do completely agree that there is a need for
at least one operator that constrains both the compiler and the CPU.

> >>>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.
> 
> Can you provide an example where refcounting using relaxed increments is 
> broken by an interrupt handler, but not broken if the increments are 
> "volatile relaxed" (reordered by hardware but not by compiler)? 

Yes, but it will take me a bit to tease a nice example out of a larger
code base.  I have been intending to do this for awhile.  :-/

						Thanx, Paul