> If you aren't going to bother understanding ordering semantics, it is unlikely you can write a safe lock-free algorithm anyway. I think the implicit suggesti

> If you aren't going to bother understanding ordering semantics, it is unlikely you can write a safe lock-free algorithm anyway. I think the implicit suggestion here is that the target audience for this abstraction is actually two separate developers: 1. A developer who doesn’t know much about locking semantics, but can write the simple-but-slow case correctly. 2. Another developer, much later on — probably a senior SRE type — who can revisit this code and optimize it with full understanding of the constraints. (This might also be the same person, years later, with more experience under their belt.) The benefit of the way this library is designed, is that the second developer doesn’t have to completely rewrite everything just to optimize it. The naive dev’s code has already been forced into an “almost but not quite” lock-free mold by the design of the library’s API surface.