CP.con: Concurrency

???

Concurrency rule summary:

• ???
• ???

???? should there be a "use X rather than std::async" where X is something that would use a better specified thread pool?

Speaking of concurrency, should there be a note about the dangers of std::atomic (weapons)? A lot of people, myself included, like to experiment with std::memory_order, but it is perhaps best to keep a close watch on those things in production code. Even vendors mess this up: Microsoft had to fix their shared_ptr (weak refcount decrement wasn't synchronized-with the destructor, if I recall correctly, although it was only a problem on ARM, not Intel) and everyone (gcc, clang, Microsoft, and Intel) had to fix their compare_exchange_* this year, after an implementation bug caused losses to some finance company and they were kind enough to let the community know.

It’s worth noting that volatile in C++ is not related to concurrency or parallelism in any way. Some languages have chosen to give it threading-related semantics, so programmers familiar with such languages tend to think that the meaning is similar. Sadly, these programmers are mistaken. The C++ standard provides some ordering guarantees on volatile operations, but these guarantees are far fewer and weaker than the guarantees on threading primitives. Therefore, using volatile in place of threading primitives in portable code is both unsafe and highly discouraged.

if (source->pool != YARROW_FAST_POOL && source->pool != YARROW_SLOW_POOL) {
    THROW(YARROW_BAD_SOURCE);
}

??? Is std::async worth using in light of future (and even existing, as libraries) parallelism facilities? What should the guidelines recommend if someone wants to parallelize, e.g., std::accumulate (with the additional precondition of commutativity), or merge sort?

???UNIX signal handling???. May be worth reminding how little is async-signal-safe, and how to communicate with a signal handler (best is probably "not at all")