5 ms·
The author is incorrect in the section about memory fences. x86 has strong memory ordering [1], which means that writes always appear in program order with resp
by acallan 12y ago
The author is incorrect in the section about memory fences. x86 has strong memory ordering [1], which means that writes always appear in program order with respect to other cores. Use a memory fence to guarantee that reads and writes are memory bus visible.
The example that the author gives does not apply to x86.
[1]There are memory types that do not have strong memory ordering, and if you use non-temporal instructions for streaming SIMD, SFENCE/LFENCE/MFENCE are useful.
- martincmartin 12y agoThe authors point still holds if writes might not appear in program order on other CPU sockets, not just other cores within the same socket. Do you have a reference for the strong memory ordering on x86? I'd like to read more about it.
- rayiner 12y agox86 enforces (essentially) total store order across all sockets: http://www.cl.cam.ac.uk/~pes20/weakmemory/index3.html http://www.cl.cam.ac.uk/~pes20/weakmemory/index3.html. The barriers are still useful for kernel code because other processors on the machine usually don't participate in the cache-coherency protocol.
- Animats 12y agoModern X86 machines do not quite have strong memory ordering. Loads may be reordered with older stores to different locations. This breaks some of the overly clever "lock free" algorithms: http://bartoszmilewski.com/2008/11/05/who-ordered-memory-fences-on-an-x86/ http://bartoszmilewski.com/2008/11/05/who-ordered-memory-fen... http://preshing.com/20120515/memory-reordering-caught-in-the-act/ http://preshing.com/20120515/memory-reordering-caught-in-the... This whole area is very touchy and easy to get wrong. Further reading: https://software.intel.com/en-us/articles/tsx-anti-patterns-in-lock-elision-code https://software.intel.com/en-us/articles/tsx-anti-patterns-...