[cpp-threads] Implicit Conversion for Atomics

[Paul E. McKenney]

On Tue, Jan 22, 2008 at 12:28:18PM -0800, Herb Sutter wrote:
> 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.

Which by the way is one reason that the academic lock-free papers have
had so little impact on practitioners -- the code in those papers, even
when free of other bugs, often fails to run on real (non-SC) systems.  ;-)

> 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.

I believe that it is useful to think in terms of "productivity"
and "performance" programmers, paraphrasing from David Patterson.
Neither SC nor non-SC atomics are in any way appropriate for productivity
programmers.  Instead, things like SQL have done the best job of providing
shared-memory parallel performance to this group.

I agree that well-designed projects will limit use of atomics (SC and
otherwise) to a small body of performance-critical code that is very
carefully designed and implemented.  But I am not at all convinced
that SC atomics are any easier to use than the non-SC store-release
and load-acquire primitives.  Nor do I expect to see a well-designed
experiment evaluating the difference any time soon.  ;-)

But as I have said before, tricky high-performance code should be very
carefully designed and implemented, and should further be embedded into
a good API.

> > > 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. :->