[cpp-threads] Implicit Conversion for Atomics

[Herb Sutter]

Haven't read the proposal yet (I will!) but to comment on this part as someone who's presenting it now:

> > I'd also add that
> >
> >     Implicit Load Encourages SC-focused Presentations

That's going to be true anyway, with or without implicit load. :-) Even nearly all the academic lock-free papers don't say where the fences/etc. should go and assume SC, and that's a far higher audience bar than industry presentations.

Frankly, even using SC atomics is very hard for experts. I've said that before, but in the past few months I've taught lock-free coding using SC atomics to groups of advanced-to-expert C++ programmers, and in the group exercises where they write "simple" functions they still consistently make a variety of mistakes.

I don't think anybody (including the proponents of non-SC atomics) is proposing that non-SC atomics be used by programmers directly, only by a handful of hard-boiled guru-level library writers who provide library abstractions (e.g., a ref_count type) for other programmers to use. Talking about simple examples using non-SC atomics has consistently led us into deep "is this code right and what does it do?" discussions even among the handful who designed the non-SC atomics.


> > although, to be honest, so do the default memory_order_seq_cst arguments.
> > I'd certainly prefer it if articles and papers state the minimal memory
> > ordering requirements for each atomic op, instead of just assuming SC.

Not even most guru-level refereed papers try to do that. The few that have tried have generally been vulnerable to errata followups. :->

> I think there are both positives and negatives to your point.  Does this
> paragraph capture the issue?
>
> Presentations, articles, and papers
> will likely assume or require sequentially-consistent operations,
> which are often stronger than algorithms require.
> The consequences are that
> presented algorithms are more accessible but less efficient.

No. Besides that "more accessible" should be something like "understandable" per above :-), the other minimal change would be to change the end to be "...but potentially less efficient on some platforms." On many platforms (e.g., x86 and x64) and for many use cases (e.g., DCL, ref counting) the performance difference between SC atomics and less-than-SC atomics is expected to be zero or unmeasurable. Right?

I personally expect some vendors will be likely to implement the C++0x non-SC atomic variants with SC semantics anyway (i.e., make dropping below SC a no-op on the platforms they care about, and document/warn that using the relaxed features has no effect on this implementation and is not recommended unless you're trying to write code that is portable to a weaker hardware platform), unless they find a significant performance difference for a real use case of course.

Herb