[cpp-threads] Yet another visibility question

[Peter Dimov]

Raul Silvera wrote:

> If you have such a model, where all ordering must be explicit, then it
> makes sense to have fine-grained fencing. I'm not sure at what level
> you consider fencing messy -- are you concerned about the mathematical
> formulation of the model? A lot of the current practice on parallel
> programming does rely on explicit fences, and they have been
> successfully employed on many parallel applications; a great example
> of this is the Linux kernel.

The two models are operation+label and "free barrier". Other things being 
equal, op+label is usually finer-grained. If you have:

load.raw x
load.acq y
op

the upper load can be moved below op. Under the equivalent

load.raw x
load.raw y
#loadload | #loadstore // 'acquire' fence
op

the upper load cannot be moved below op.

Both models support (in principle) finer-grained constraints that affect 
only loads or only stores.

load.hlb x // hoist-load barrier (acq for loads)
load.raw y // cannot be hoisted above the hlb
store.raw z // this can

and

load.raw x
#loadload
load.raw y
store.raw z

We've (reluctantly) decided to not include 'hlb' and friends in the MM 
mainly because of specification difficulties.

I'm not sure what is the current status of the MM with respect to the full 
fence. It could turn out that specifying a full fence is comparable in 
complexity to specifying a full bidirectional fence model.

Another thing going in favor of the op+label approach is that it maps very 
cleanly to x86. :-)