[cpp-threads] Alternatives to SC

[Herb Sutter]

Doug wrote:
> And anyway, I think Herb has a different sort of "simplicity"
> in mind -- for people who want to know as much about concurrency
> as I want to know about, say, building tax-preparation software (i.e.,

Mmm, not exactly. I just want something usable by expert programmers who do understand at least lock-based concurrency. :-)

> as little as possible). In those cases, you'd like to tell them
> "Use this high-level framework that automates most of your
> concurrency control needs, and when in doubt about anything else,
> use a lock". Which is normally perfectly fine advice (and which
> is of course irrelevant to the SC-atomics discussion).

How is it irrelevant, if atomics are the next-lower tool below locks? When programmers want to avoid locks, for either composability/correctness or performance, aren't these atomics the first thing they'll reach for?

Let me put it this way: _Average_ real-world programmers who understand locks encounter situations where they reasonably want/need to avoid the lock, either because of expense or to avoid the potential for deadlock. What's the next level down -- what do we give those average programmers that they can use reliably to write code that reason about confidently?

(Unfortunately, at least today, the answer isn't TM, and I hope TM will wildly succeed but it can't eliminate all locks because some resources aren't transactable).

Herb