4 ms·
> A barrier instruction forces all memory operations before it to complete before any memory operation after it can begin. That is, a barrier instruction effect
by liblfds-temp 2y ago
> 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.
- throwaway17_17 2y agoJust 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?
- liblfds-temp 2y agoMmm. 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".
- Maxatar 2y agoBarriers 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.
- gpderetta 2y agoThe 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.