[cpp-threads] Web site updated

[Paul E. McKenney]

On Wed, Feb 14, 2007 at 12:21:29AM +0200, Peter Dimov wrote:
> Boehm, Hans wrote:
> 
> >But I think that combining accesses can also be a problem at user
> >level, for other reasons.  If I write
> >
> >Thread1:
> >for(;;) {
> >    a.store_relaxed(0); // or release
> >    a.store_relaxed(1);
> >}
> >
> >Thread2:
> >while (a.load_relaxed());
> ><do something useful>
> >
> >Should I expect thread 2 to eventually make progress?  Clearly if the
> >first a.store_relaxed() is elided, the answer is no.  But an answer of
> >"yes" is probably more desirable.
> 
> This is an interesting example since thread 1 can be equivalently 
> transformed to
> 
> a.store_relaxed(0);
> 
> for(;;) {
>    a.store_relaxed(1); // or release
>    a.store_relaxed(0);
> }
> 
> where combining the stores will give a different result. But does it 
> correspond to a sensible real-world case?
> 
> Either way, my point is that we already have a "dumb mode" switch, it's 
> called volatile.

Which unfortunately generates extra code on some compiler/hardware
combinations.  I would be very happy if we could redefine volatile
to constrain the compiler but not the CPU, but I don't see any way to
get there from here.

Nice thought, but seems infeasible.

This is one reason I was putting forward the barrier() primitive
earlier that constrains the compiler but not the CPU.

							Thanx, Paul

>                  If a is marked volatile:
> 
> volatile int a;
> 
> for( ;; )
> {
>    atomic_store_relaxed( &a, 0 );
>    atomic_store_relaxed( &a, 1 );
> }
> 
> this gives the programmer the intended effects of a thread toggling a 
> between 0 and 1. So this is one way to keep volatile and atomic separate 
> and orthogonal. We already decided to not make volatile imply atomic, so it 
> only makes sense to consistently apply this principle in the other 
> direction and state that atomic does not necessarily imply volatile.
> 
> Or not. But I can see many optimization opportunities being lost. It would 
> be rare for two relaxed accesses to appear next to one another in the 
> source code, but inlining several functions and then reordering the basic 
> block will routinely produce such examples. In fact, _release and _acquire 
> will suffer even more because of the redundant barriers.
>