[cpp-threads] out-of-thin-air results, depndency-based ordering again.

[Peter Dimov]

Boehm, Hans wrote:
> I've been trying to generate a revision to N2052 that prohibits
> out-of-thin-air results without enforcing anything like
> dependency-based ordering, since I'm increasingly convinced that's
> undefinable, even in the limited cases in which we previously made
> the attempt.  After convincing myself that the alternative approach I
> had in mind wouldn't work either, I wrote up a summary of the state
> of affairs, with a proposal to approach this a bit differently, in
>
> http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/thin_air.html

I think that this will work.

> This does not address getting dependency-based ordering for the sake
> of dependency-based ordering.  Following Herb's approach, might it be
> possible to handle that in limited cases with a more specific
> primitive, e.g. a function that retrieves both an atomic pointer and
> its referent (if the pointer is non-null), ensuring that the pointer
> access is ordered before the accesses to the object?

This doesn't cover the common case of

if( X * r1 = atomic_load( &p ) )
{
    int a = r1->f();
}

since X may not be copyable. We can provide

T* atomic_load_address( T** pp );

(maybe with an appropriately renamed suffix) and state that when it returns 
a nonzero value r, the storage of *r is guaranteed to be visible to the 
current thread (but other memory locations may not be). This still doesn't 
cover transitive orderings though:

if( X * r1 = atomic_load_address( &p ) )
{
    int a = r1->p2->g();
}

*r1 is visible, but *r1->p2 may not be, since r1->p2 is an ordinary load, 
not atomic_load_address. And r1->p2->g() can be hidden inside r1->f(), so we 
can't insert the atomic_load_address there.

Returning the whole object will work for simple (and small) C structs, but 
not for anything nontrivial. The copy overhead for a std::string (for 
example) or even a shared_ptr will make the acquire barrier seem like a 
no-op in comparison.