Memory Barriers Are Like Source Control Operations
If you use source control, you’re on your way towards understanding memory ordering, an important consideration when writing lock-free code in C, C++ and other languages. In …
If you use source control, you're on your way towards understanding memory ordering, an important consideration when writing lock-free code in C, C++ and other languages. In my last post, I wrote about memory ordering at compile time , which forms one half of the memory ordering puzzle. This post is about the other half: memory ordering at runtime, on the processor itself. Like compiler reordering, processor reordering is invisible to a single-threaded program. It only becomes apparent when lock-free techniques are used - that is, when shared memory is manipulated without any mutual exclusion
Explore this link on the map →saved by
related reading
- Who ordered memory fences on an x86? | Bartosz Milewski's Programming Cafebartoszmilewski.com
- research!rsc: Hardware Memory Models (Memory Models, Part 1)research.swtch.com
- C++11 Memory Modelpeople.cs.pitt.edu
- LittleBookOfSemaphores.pdfgreenteapress.com
- Inter-process communication in Linux: Shared storage | Opensource.comopensource.com
- Reading 16: Mutual Exclusionweb.mit.edu
- BrrrVizbrrrviz.com
- Optimization barriers | Pintos Documentationcs162.org
- The Go Memory Model - The Go Programming Languagego.dev
- Unreliable Guide To Locking — The Linux Kernel documentationdocs.kernel.org
- Zenbleedlock.cmpxchg8b.com
- Locking in WebKit | WebKitwebkit.org