> A barrier instruction forces all memory operations before it to complete before any memory operation after it can begin. That is, a barrier instruction effectively reinstates sequential consistency at a particular point in program execution.
> Of course, this is exactly the behavior we were trying to avoid by introducing store buffers and other optimizations. Barriers are an escape hatch to be used sparingly: they can cost hundreds of cycles.
I may be wrong, but I think to readers who do not already know what barriers do and are, this makes barriers seem like blocking behaviours.
Just to clarify your comment via a question: are you pointing out that barrier instructions are a scheduling ‘issue’ that the processor uses to order instructions versus something like a memory read that actually requires a pause in the execution of instructions?
Mmm. Sort of the former, but really my thought was this : "you have a barrier, fine, but that does not mean once you hit/pass the barrier, all prior read/writes are complete - in fact, the completion of earlier reads/writes only occurs at the first read/write after the barrier".
Barriers can induce blocking behavior though. A store barrier followed by a store operation can result in a blocking operation until the store buffer is flushed, and similarly for a load barrier.
The usual way that barriers were implemented was to simply stall the CPU pipeline. So yes, they do indeed have blocking semantics. IIRC mfence still does stall the pipeline on x86, but I think the CPU is a bit smarter for locked instructions.
I'm about to move into ARM development for a new-ish AI accelerator. Until now, I've mostly developed for x86.
In preparation for this, I've been reading up on ARM's looser memory consistency model, and C++'s rules regarding this. It's been pretty eye-opening.
I'm looking forward to seeing how much that ARM codebase takes advantage of the weaker guarantees that ARM permits. It seems like a trade-off of scalability vs. correct-code complexity.
18 comments
[ 4.3 ms ] story [ 55.9 ms ] threadit seems to be coming up kinda 404 for me. thank you !
The programming-language-specific parts are more focused on C than C++ (which is my main focus), but I've still found it quite helpful.
I haven't looked at the other sources people are mentioning though, so no idea how it compares.
[0] https://cdn.kernel.org/pub/linux/kernel/people/paulmck/perfb...
At least for me, it requires (a) a good reason for powering through it, (b) a good night's sleep, and (c) Adderall :)
Just saying, it may not be the most effective / efficient way to learn what you want to know.
I was taught that a deeper understanding leads to better software/solutions and I strive to live up to my mentor dedication :)
aside from being fun, it just makes everything so much easier when it's not "magic"
> Of course, this is exactly the behavior we were trying to avoid by introducing store buffers and other optimizations. Barriers are an escape hatch to be used sparingly: they can cost hundreds of cycles.
I may be wrong, but I think to readers who do not already know what barriers do and are, this makes barriers seem like blocking behaviours.
In preparation for this, I've been reading up on ARM's looser memory consistency model, and C++'s rules regarding this. It's been pretty eye-opening.
I'm looking forward to seeing how much that ARM codebase takes advantage of the weaker guarantees that ARM permits. It seems like a trade-off of scalability vs. correct-code complexity.