[cpp-threads] Yet another visibility question

[Paul E. McKenney]

On Tue, Dec 19, 2006 at 08:44:21PM -0500, Doug Lea wrote:
> Peter Dimov wrote:
> >Boehm, Hans wrote:
> >
> >>We can argue about whether this should be considered a real
> >>dependency. But as I argued earlier with Peter, if we assume it
> >>isn't, I think dependency-based ordering becomes largely useless to
> >>the programmer, since I can't reason about it without looking through
> >>abstraction boundaries.
> >
> >I don't agree. Provable dependencies are not uncommon and in this case I
> >can use a raw/release atomic. Unprovable dependencies will need an
> >acquire. I can live with that.
> >
> 
> Maybe I'm not following this discussion closely enough, but it
> would seem that if you want to impose an ordering, then you
> should always state it, and then let the compiler worry about
> whether that actually requires a fence on the platform you run on?
> 
> In other words, the following would almost never be correct:
>   r1 = x.load_raw(); // should be load_acquire
>   r2 = *r1;
> And maybe tools could help find such errors.
> 
> Or am I missing the point?
> 
> The alternative of defining dependencies seems to me to
> be a losing battle, at least in C++.
> 
> -Doug

For whatever it is worth to this group, all of the parallel projects
I have been involved with have used explicit ordering directives.
But many of the projects also have rules against gratuitous ordering
directives -- the desire is to instead bury them in higher-level
primitives, such as locking, list traversal, atomic operations, etc.

						Thanx, Paul