Back to Basics: Concurrency - Arthur O'Dwyer - CppCon 2020 

Glad you enjoyed it!

Glad to hear it!

Glad it was helpful!

Glad to hear it!

I had thought so, but it appears I was wrong; the compiler cannot hoist the atomic read out of the loop. The advice at @17:54 is still correct - you should still be very careful and beware of situations where the compiler might reorder or coalesce or eliminate atomic accesses in general - but this particular while-loop is NOT actually such a situation. For some (mostly theoretical) examples of how a compiler might optimize atomic access patterns, see JF Bastien's N4455 "No Sane Compiler Would Optimize Atomics" www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4455.html

@@Quuxplusone Herb Sutter in some of his presentations promotes spinlocks - which I was surprised about but after watching him I bought into it. He places requirements on the lock - i.e. limit what code the lock is covering. Using a printf that might block would be bad for a spinlock though.

The read is prevented from moving using default memory order, “sequentially consistent”. The presenter was incorrect

No, Arthur got this wrong. Compilers have to assume that other threads *are* changing the values of std::atomic objects between reads, because concurrent read + write is not data race UB. (For non-atomic variables, data race UB is what allows this transformation which compilers do in practice.) (6.9.2.3) Forward progress / 18 : An implementation should ensure that the last value (in modification order) assigned by an atomic or synchronization operation will become visible to all other threads *in a finite period of time.* (33.5.4) Order and consistency [atomics.order] / 11: Implementations should make atomic stores visible to atomic loads *within a reasonable amount of time.* These are only "should" requirements in the ISO C++ standard, but this transformation would make an implementation useless in practice. (The reason those requirements aren't stronger than "should" is to allow running multi-threaded programs on a heavily-loaded OS with a scheduler that doesn't guarantee fairness, e.g. that can starve a thread indefinitely if there are other high-priority (or real-time priority) threads taking all the CPU time. Not because the authors of the standard think it's reasonable for a compiler to statically decide that a loop should never see a store if it wasn't visible before the first iteration.) All of this applies even with memory_order_relaxed, @creativeprocessingunitmk1587 . This hypothetical transformation wouldn't reorder the load wrt. any other accesses so seq_cst isn't involved.

You're correct, there's a typo on slide 49. The while-loop condition should have a "!" at the front. Thanks!

You're right that the lambda is missing a capture: it should be [&], not []. But the asterisk in `return *conn_;` is correct: conn_ is an optional, and we want to return a Connection&, which means we need to crack open the optional to get at its actual Connection value. We can do that either as `return conn_.value()` (which will check conn_.has_value() and throw if it doesn't) or `return *conn_` (which doesn't bother with the check).

There is no memory barrier (there's an atomic load which is a very different thing), but even if there was it would not make a difference, because "ready is never set" is a completely valid execution: atomics work in terms of happens-before and happens-after, and only ensure consistency within those bounds (as well as the access itself being atomic obviously). Here the code will *probably* happen to work because compilers don't bother too much around atomics currently (as it's fiddly to optimise and pretty unlikely to yield much benefit), but per-standard it's absolutely not *guaranteed* to work.

The read is prevented from moving using default memory order, “sequentially consistent”. The presenter was incorrect

The read is prevented from moving using default memory order, “sequentially consistent”. The presenter was incorrect

There *is* a (typo-) bug in the blue/green example (see MaceUA's comment "58:00 is there a typo..."), but it's not an ABA problem. Your scenario can't happen because it depends on the idea that thread A can ever allocate the latest `ConfigMap` at the same address as the `*blue` originally observed by thread B. But that would imply that the object at `*blue` had been destroyed and deallocated... and that can't have happened, because thread B has been holding a shared_ptr on `blue` the entire time. If variable `blue` were a raw pointer, then we'd have that ABA problem, and worse, because `*blue` might get deallocated by some other thread right in the middle of our copy-constructing it into `*green`! By making `g_config` and `blue` into shared_ptrs, we eliminate that particular possibility.

That is solved by the compare_exchange_strong call in the while condition. The function checks if the current representation of the config matches the expected (blue), if so, modify the value and return true, but if there were other threads already changed the config, the function will return false. Actually there's a typo in Authur's code, it should rather be `while(!compare_exchange_string(...));`, when the modification fails, then it retries.

No, Arthur got this wrong. Compilers have to assume that other threads *are* changing the values of std::atomic objects between reads, because concurrent read + write is not data race UB. (For non-atomic variables, data race UB is what allows this transformation which compilers do in practice.) (6.9.2.3) Forward progress / 18 : An implementation should ensure that the last value (in modification order) assigned by an atomic or synchronization operation will become visible to all other threads *in a finite period of time.* (33.5.4) Order and consistency [atomics.order] / 11: Implementations should make atomic stores visible to atomic loads *within a reasonable amount of time.* These are only "should" requirements in the ISO C++ standard, but this transformation would make an implementation useless in practice. (The reason those requirements aren't stronger than "should" is to allow running multi-threaded programs on a heavily-loaded OS with a scheduler that doesn't guarantee fairness, e.g. that can starve a thread indefinitely if there are other high-priority (or real-time priority) threads taking all the CPU time. Not because the authors of the standard think it's reasonable for a compiler to statically decide that a loop should never see a store if it wasn't visible before the first iteration.) All of this applies even with memory_order_relaxed. This hypothetical transformation wouldn't reorder the load wrt. any other accesses so seq_cst isn't involved. RU-vid deletes comments with links, but search for Why set the stop flag using `memory_order_seq_cst`, if you check it with `memory_order_relaxed` on Stack Overflow

You are, in fact, wrong about that. :) C++11 introduced a formal memory model that specifies exactly when one event may be guaranteed to happen-before another. On slide 10, we are guaranteed that the write happens-before the thread exits (because they happen in the same thread); and the thread exit happens-before `join` returns (because thread::join() is a synchronization point); and the return from `join` happens-before the read of `result` (again because they happen in the same thread). So the read and the write definitely don't race with each other; the write definitely happens first. Adding `volatile` to this code wouldn't make it any more or less correct; and vice versa, adding `volatile` to wrong code generally doesn't make it correct. As to what the compiler/hardware have to do, involving memory fences and cache coherency and so on, in order to make that read load the correct value from memory, "that's not my department"; all I'm telling you is what the correct value _must be_ in this case, according to the C++ Standard. On the topic of `volatile` specifically, see quuxplusone.github.io/blog/2022/01/28/volatile-means-it-really-happens/

Using a condition variable

With an atomic that you check every so often. (Or with C++20 std::jthread which has cancel functionality.) Arthur is wrong about compilers being allowed to assume it doesn't change. Compilers have to assume that other threads *are* changing the values of std::atomic objects between reads, because concurrent read + write is not data race UB. (For non-atomic variables, data race UB is what allows this transformation which compilers do in practice.) (6.9.2.3) Forward progress / 18 : An implementation should ensure that the last value (in modification order) assigned by an atomic or synchronization operation will become visible to all other threads *in a finite period of time.* (33.5.4) Order and consistency [atomics.order] / 11: Implementations should make atomic stores visible to atomic loads *within a reasonable amount of time.* These are only "should" requirements in the ISO C++ standard, but this transformation would make an implementation useless in practice. (The reason those requirements aren't stronger than "should" is to allow running multi-threaded programs on a heavily-loaded OS with a scheduler that doesn't guarantee fairness, e.g. that can starve a thread indefinitely if there are other high-priority (or real-time priority) threads taking all the CPU time. Not because the authors of the standard think it's reasonable for a compiler to statically decide that a loop should never see a store if it wasn't visible before the first iteration.) Search for Why set the stop flag using `memory_order_seq_cst`, if you check it with `memory_order_relaxed` on Stack Overflow; you only need "relaxed" memory ordering for both setting and checking such a flag.

The read is prevented from moving using default memory order, “sequentially consistent”. The presenter was incorrect

Arthur got this wrong. Compilers have to assume that other threads *are* changing the values of std::atomic objects between reads, because concurrent read + write is not data race UB. (For non-atomic variables, data race UB is what allows this transformation which compilers do in practice.) (6.9.2.3) Forward progress / 18 : An implementation should ensure that the last value (in modification order) assigned by an atomic or synchronization operation will become visible to all other threads *in a finite period of time.* (33.5.4) Order and consistency [atomics.order] / 11: Implementations should make atomic stores visible to atomic loads *within a reasonable amount of time.* These are only "should" requirements in the ISO C++ standard, but this transformation would make an implementation useless in practice. (The reason those requirements aren't stronger than "should" is to allow running multi-threaded programs on a heavily-loaded OS with a scheduler that doesn't guarantee fairness, e.g. that can starve a thread indefinitely if there are other high-priority (or real-time priority) threads taking all the CPU time. Not because the authors of the standard think it's reasonable for a compiler to statically decide that a loop should never see a store if it wasn't visible before the first iteration.) All of this applies even with memory_order_relaxed, @creativeprocessingunitmk1587 . This hypothetical transformation wouldn't reorder the load wrt. any other accesses so seq_cst isn't involved. re: mutex: on Linux / glibc, std::mutex is "light weight", making no system calls in the uncontended case. It spin-waits for a short time, then makes a futex system call to sleep until notified. (Same API that C++ .wait() and .notify_one() use.) So if there's contention you get futex system calls, if not you just get atomic RMWs in user-space on the mutex object. This is usually better than a spin-wait loop, if you don't manually fall back to C++20 .wait(). IIRC, MSVC on Windows has a "heavy" std::mutex that always calls into the kernel for unique_lock, but maybe not for some other ways of using it. And yes, that's slow, with Spectre / Meltdown mitigations that's probaly even worse than 1000 cycles.