That's why you should use absolute indexes. He called it unnecessary complexity, but I'd say it's the other way around, It makes most things simpler, Including telling the difference between full and empty.
@1:15:07 can someone explain why it would get stuck in the while loop. It seems to me that if the 1st reader changed the oldReadPos then compare_exchange_strong will return false for the 2nd reader; but on the second run through the loop the 2nd reader will read from the ringBuffer; the 1st reader would not be there to change the readPos so compare_exchange_strong will return true and break the loop. I don't see why the 2nd reader would be stuck in an infinite loop if no one else is changing the readPos.
Wonder why nobody noticed, but the SPMC example is fundamentally wrong as pop(...) returns a reference to an element which could be modified by the writer before the caller of the pop would be able to read/copy it. (Returning a reference is almost always a bad idea in MT env.). Idem, it is not easy, imho, to correct the pop here to fix this problem because if you move the line "returned Element = ringBuffer[oldReadPos];" after the CAS check, then the writer again may be able to modify this value before the reader actually moves it from the buffer. Another minor point is that atomic::compare_exchange_strong (and weak) already replaces expected (=oldReadPos) with the contained (=readPos) value if it returns false, so it is no need to do it twice, as in the example....
If I'm understanding your hesitation; pop() doesn't return a reference to an object in the ring buffer. It takes a reference as a parameter and copies the object from the ring buffer into the external object (that pop() has a reference to) using T::operator=(const T&). The client has its own, safe copy before the CAS check. If the write pointer was able to overtake oldReadPos between T::operator=(const T&), that means another thread has advanced the read pointer. Then the CAS check will fail in this thread and the function will go back to the top of the loop. Let me know if I'm missing something though. It's a great thought experiment. Good point on the exchange changing the value on failure. I never realized that :P
Code at 1:16:56 seems to have an ABA problem in pop(). readPos.compare_exchange_strong could be fooled if the writer and another reader wrap the positions.
44:06, how u make sure no one is using an object ur going to dispose? : D... I understand the talk is just about atomics, but shouldn't completely skip the lifetime management part really, it's important.
As I'm just now learning about lock-free and std::atomics (relatively new hobby programmer here), this talk was incredibly informative and my eyes are now large with a thirst for more knowledge on this stuff lol Very well put together in my opinion and was very easy to follow along
Atomic compare_exchange's "otherwise does nothing" is a bit ambigious: if the value of the atomic does not equal expected, then expected will be set to the current value of the atomic. For this, expected is always a reference-type.
This could be damaging in a wait loop no? If you set Expected to a value then attempt to while(){} if expected is set to the value the first time around next iteration it will view expected as good and perform the swap... this is not desirable is it?
TFW you dig up old code... something is wrong so you come back to the video... you see a comment that might help and expand the replies only to find out you were just as confused 10 months ago as you are now.
![Lock-free programming with modern C++ - Timur Doumler [ACCU 2017]](/img/logo.svg){kind=logo}
