Advanced Topics: Software Memory Barriers 

My goal was to avoid talking about hardware memory reordering as much as possible because it's a separate issue (and warrants a dedicated discussion). If your instructions have already been scheduled in the wrong order by the compiler, it won't work even on a sequentially consistent machine, so you've lost the war before you've even executed your application. I'll be doing video on hardware memory reordering and hw barriers soon! Cheers, --Nick

@@CoffeeBeforeArch Ahh so you've actually forseen this problem already. Of course you're miles ahead of me. I should've expected that by now. I just always seem to have to talk about what certain memory primitives do and more importantly what they not do when talking to other programmers.

Memory models are a niche topic that unfortunately many people don't have a good foundation in. It's also a place where intuition can fail you. Fortunately on x86, it's a relatively strict memory model where the reordering of stores is not even possible, so the example is safe. On a platform like ARM, with a much weaker consistency model, you would need a barrier (e.g. like the ARM linux kernel spin lock that uses the smp_mb() macro that expands to the dmb instruction).

Thanks for the suggestion! I'll see if it fits in with any of the other topics I have planned. Cheers, --Nick

Good question, I also want to know.

@@chenyu8553 technically, this is an incorrect use of volatile, I believe it should be an atomic with relaxed memory. The thing you want to guarantee is that now_serving becomes visible to other cores. An atomic or volatile guarantees that reads and writes always goes through memory and doesn't use a local register copy. The difference being is that CPUs have visibility on other CPU's memory operations (since memory is shared) whereas registers are private to a logical CPU (hyperthreads get their own copy of the register state but share the compute units with other hyperthreads). The reason why volatile is not technically correct is a bit subtle and is the reason why C++11 introduced atomics in the first place. Probably the explanation would make for good content @CoffeeBeforeArch!

@@chenyu8553 volatile guarantees intra-thread ordering and inter-thread visibility but without ordering and, thus, not inter-thread synchronization. The order in which other threads see volatile memory accesses is not guaranteed to align with the order in which they are made by a given thread. This is why atomics and memory_order semantics are required to ensure desired behavior actually occurs in program execution. As stated by @DoobooDomo below.

Not sure what your point is. The guy has started from a single concept of software memory barrier and has another video about hardware memory barrier. This is common sense to move step by step for novice audience. You know stuff doesn't mean you should be told all at once. Now stay quite and check all videos.

@@267praveen Erg's tone is a little harsh, but he's correct. Even teaching to novices, it is probably a good idea to avoid teaching things that are actually wrong. This use of volatile is incorrect (it should be an atomic with relaxed memory ordering), but it is a common error because that's what people did before C++ had an explicit memory model with atomics etc. (I think this use of volatile is also correct in Java). I agree this stuff is subtle, and made-up (but important) concepts like the "abstract C++ model" make things more difficult for all learners. To end on a positive note: I really enjoyed Coffee's treatment on different spinning policies in his spinlock playlist.