[cpp-threads] Yet another visibility question

[Herb Sutter]

Thanks for the excellent summary as usual, Hans.

Hans wrote:
> > I would really prefer a model in which programs that use high-level
> > atomics to synchronize, and have no races on ordinary variables,
> > behave sequentially consistently.
[...]
> > At least Herb doesn't think anything at a lower level is useful.

Slight correction: As you note below, I do think that for specific uses where they are known to have important performance benefits it can be useful to provide judiciously chosen abstractions that are at a lower level (e.g., a rc_uint type, a dcl_flag type), with explicit guidance on the correct way to use them.

You are right that I don't think that providing non-SC primitive operations (e.g., an explicit fence, a non-SC fetch-add-store) is useful because they are too brittle even for experts to use reliably. I think that has been proven true in practice for fences, and even the dozen experts who can use them reasonably correctly (and without overusing them and killing the performance gain that was the whole point of dropping down this far, which is far too common) would be better served by abstractions. We have such experts here; wouldn't you rather write ref count code or DCL code with an rc_uint or dcl_flag type instead of writing the fences by hand every time?

> > But my impression from past committee meetings is that most people also
> > want a lower layer.  The alternative would be to try to capture
> > all the interesting use cases in more specialized libraries instead.

Yes.

BTW, it has been pointed out that to do this we still have to specify lower-level ordering in the model. That's probably true, but it does not mean we have to expose those knobs via lower-level primitive operations. My concern is that it will lead people down a bad path where they cannot succeed (though they may appear to succeed for a while, because they don't notice the bugs or they won't happen to manifest the same way on all implementations).

> > I think we agree that there are cases in which you can get better
> > code by allowing explicit fences
[...]
> > If we get to the question of adding explicit fences, my impression is
> > that opinions are strongly divided.  But I think that is essentially a
> > complexity vs. expressivity and performance trade-off.

Questions:

  - What are those cases where you get better performance?
      (I recall ref counting, DCL, and marking... what else?)
  - How much "better"?
  - And why are these cases not amenable to abstraction?

Even if we did the full lower non-SC layer, which I think we shouldn't, IMO we need those abstractions anyway because they're a vast improvement and far easier to use correctly and harder to use incorrectly -- we certainly don't want to teach every lock-free programmer the right fences for ref counting, and hope they get it right often enough, do we?

And if we think we need to support those cases via abstractions anyway, that removes that argument for providing the brittle individual knobs. Are there any other arguments for providing them?

Lawrence added (eliding to preserve the part I most strongly agree with):
> My concern with fences is [...] fences are a global act, and
> physics does not like those.

Herb