CppCon 2017: Fedor Pikus “C++ atomics, from basic to advanced. What do they really do?”

What Hacker News said

Strong rec speps · 2017-11 · on “Designing a Lock-free, Wait-free Hash Map”

No, from what I understand, you can't even do it in software anyway due to how the caches work between cores inside the CPU. Watching this was enlightening to say the least (and the presenter is very good): [this video]

Recommends chrsig · 2022-09 · on “Lockfree Algorithms (2010)”

Fedor Pikus has given a number of great talks on the subject at cppcon over the years some links, in no particular order: CppCon 2017: Fedor Pikus “C++ atomics, from basic to advanced. What do they really do? [this video] CppCon 2016: Fedor Pikus “The speed of concurrency (is lock-free faster?)" [LINK] CppCon 2015: Fedor Pikus PART 1 “Live Lock-Free or Deadlock (Practical Lock-free Programming)" [LINK] CppCon 2015: Fedor Pikus PART 2 “Live Lock-Free or Deadlock (Practical Lock-free Programming)” [LINK] CppCon 2017: Fedor Pikus “Read, Copy, Update, then what? RCU for non-kernel programmers” [LINK] Tony Van Eerd has also given some talks on lock free queues, I'll leave it as an exercise to the read

Recommends inetknght · 2025-08 · on “Without the futex, it's futile”

tl;dr: In a multi-threaded context, memory reads and writes can be reordered by hardware. It gets more complicated with shared cache. Imagine that you have core 1 writing to some address at (nearly) the same time that core 2 reads from that. Does core 2 read the old or the new? Especially if they don't share the same cache -- core 1 might "write" to a given address, but it only gets written to core 1's cache and then "scheduled" to be written out to main memory. Meanwhile, later core 2 tries to read that address, it's not in its cache, so it pulls from main memory before core 1's cache has flushed. As far as core 2 is concerned, the write happened after it read from the address even though p