[cpp-threads] High-level vs. low-level

[Herb Sutter]

Peter Dimov wrote:
> Boehm, Hans wrote:
> > The high level interface does seem to buy you some useful
properties:
> >
> > 1) Things like double-checked locking work with just a declaration
> > change, as they do in Java.  My impression is that some people
> > perceive this as close to a requirement.
> >
> > 2) It can be directly applied to struct of bit-fields and the like.
> >
> > 3) Parameterization w.r.t. ordering constraints, which can reduce
the
> > amount of required library code.
> 
> Perhaps it does buy some people something; I'm not disputing that. I
have
> no interest in it, though. It doesn't seem to buy me anything. :-)

I got lost in the quoting. :-) I think you're saying you're uninterested
in the high-level part, right?

I believe the "low-level part" means explicit use of acquire, release,
and raw. Right? I have trouble thinking of (3) above as high-level, and
so when I say "low-level" below I'll include (3) above.

I suspect that the number of programmers who can program reliably using
the low-level part approaches zero (highly probable outside this group,
and possibly including some of us). I'm really concerned that not even
rocket scientist programmers can consistently write low-lock code
correctly when forced to program with explicit fences and/or explicit
acquire/release decorations.

Do people feel strongly that the low-level part is reliably programmable
by humans? If so, I would like the opportunity to test this hypothesis
empirically. In particular, I have in mind to select a few brief
lock-free code examples (no more than half a dozen), each to be
interpreted using (a) Java-style volatile semantics and (b) atomic<raw>
or similar semantics, and then ask a set of freshmen and a set of
experts (including the proponents of the low-level model) to answer
questions about the examples. I suspect that for both groups, both
response time and correctness will vary greatly between (a) and (b).


> >> * I'd really like to see
> >> atomic_decrement_<order1,nonzero>_<order2,zero>, or at least
> >> atomic_decrement_release_acquire.

Sorry if I missed it: What would these do?

> >> This primitive is essential
> >> for correct reference counting. The closest the current
> >> proposal has is atomic_fetch_add_ordered. It may be argued
> >> that it's close enough for all contemporary platforms.
> 
> > I think the more precise version would be a tough sell.  My
impression
> > is that there is already a lot of concern that the current version
is
> > too complicated.
> 
> I'm not sure that I want to sell anything to anybody yet. My interest
is
> mostly because Boost needs an atomics library backbone to support the
> various reference count and mutex implementations, so it would be nice
if
> I could just implement the current proposal, or more specifically, its
> low-level part. I have no use for the high-level part at the moment.

Herb