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
saved by
related reading
- Who ordered memory fences on an x86? | Bartosz Milewski's Programming Cafebartoszmilewski.com
- Linux kernel memory barriers — The Linux Kernel documentationdocs.kernel.org
- research!rsc: Hardware Memory Models (Memory Models, Part 1)research.swtch.com
- C++11 Memory Modelpeople.cs.pitt.edu
- The Go Memory Model - The Go Programming Languagego.dev
- LittleBookOfSemaphores.pdfgreenteapress.com
- Inter-process communication in Linux: Shared storage | Opensource.comopensource.com
- Problem Set 4: Memory Scrambleweb.mit.edu
- Reading 16: Mutual Exclusionweb.mit.edu
- BrrrVizbrrrviz.com
- CSAPP_2016.pdfcs.sfu.ca
- Optimization barriers | Pintos Documentationcs162.org