[cpp-threads] modes

Peter Dimov pdimov at mmltd.net
Sun May 8 01:27:24 BST 2005


Doug Lea wrote:

> But compiler-based barrier optimization for these kinds
> of cases seems straightforward. When usages are along the lines of:
>
> atomic<Stuff*> asp;
> ...
> Stuff* p = asp.read_acquire();
> if (p != null)
>    x = p->y;
>    ...
> ...
>
> If a compiler knows that its target platform doesn't
> need read barriers when all future actions are dependent
> on a branch and/or pointer deref, it can remove the barrier by itself
> without you having to use a special mode to tell it. The "all"
> part looks like a big restriction but I think rarely is.

No, this is impossible to optimize in general.

int f()
{
    Stuff * p = asp.read_acq();

    if( p != 0 )
    {
        return p->y;
    }
    else
    {
        return 0;
    }
}

The compiler has no idea whether the reads and writes in the caller of f() 
can safely be hoisted across the explicit acquire.

The only way to eliminate ddacq is to mandate that it is always present. 
This means that read_none must have a trailing rmb on Alpha, but does not 
affect anything else. 





More information about the cpp-threads mailing list