Atomics and Memory Ordering always feel like an unapproachable topic. In the sea of poor explanations, I wish to add another by describing how I re...
For further actions, you may consider blocking this person and/or reporting abuse
Pretty well-written, accessible article of a tricky subject. The exception being the last paragraph before the conclusion where you mention "full barrier" and "write-combined memory". I'm guessing that will baffle some people. But, it would have made the post much longer...
But great post overall! Synchronization is a fascinating subject that I feel is poorly understood and doesn't get enough attention. Further reading on lock-free data-structures, the ABA problem, dealing with hw/sw interrupts, spin-locks, priority inversion, and so on. See, I'm excited, is everyone else? 😁
full barrier is what SeqCst does
write-combined memory instructions are multithreaded stores
at least that is what I understood, but I think I'm right
Trying to wrap my head around fences.
Shouldn't ordering be the following?
A fence(Release) makes previous non-Release atomic stores into Release if they have a matching Acquire atomic load or matching fence(Acquire).
A fence(Acquire) makes subsequent non-Acquire atomic loads into Acquire if they have a matching Release atomic store or matching fence(Release).
I don't think so:
write(); fence(Release); store()under those rules would imply that the write() isReleasewhen in-fact the store() might be the one that is used to observe the contents of the write(), meaning the store() would have to beRelease."Promoting the store() to Release" might be the wrong imagery to use on my part. The C++ Atomics Reference describes it much more concretely:
Thanks for writing this article.
It's a pleasure to see advanced topics on dev.to.