Talk:Memory barrier

untitled

If the article contained before/after examples of how each type of fence (full, read, write) is used the article would be more informative. 24.12.24.221 (talk) 15:34, 3 March 2009 (UTC)

"Moreover, you are not guaranteed that volatile reads and writes will be seen in the same order by other processors due to caching, meaning volatile variables may not even work as inter-thread flags or mutexes." Is this really due "to caching"? Doesn't a MESI protocol, as usually employed, prevent processors from seeing an inconsistent memory state? 128.131.204.52 (talk) 09:45, 9 July 2009 (UTC)

MESI ensures consistency only on a single cacheline. --Chris Purcell (talk) 10:41, 4 September 2012 (UTC)

'Other architectures, such as the Itanium, provide separate "acquire" and "release" memory barriers which address the visibility of read-after-write operations from the point of view of a reader (sink) or writer (source) respectively.' This doesn't seems right since I can't find any standalone memory barrier instruction with "acquire" or "release" semantics. Sergefdrv (talk) 09:52, 21 June 2016 (UTC)

Incorrect Term Appropriation

Back in 80ies, read/write memory barrier used to refer to catching memory accesses to specific memory region, like garbage collection generation. Symbolics Lisp machines had hardware support for that. https://medium.com/@MartinCracauer/generational-garbage-collection-write-barriers-write-protection-and-userfaultfd-2-8b0e796b8f7f

Now the term got hijacked to refer to Intel x86 specific sfence-style multithread syncing instructions - a totally different subject. -- NikitaSadkov (talk) 16:40, 29 April 2018 (UTC)

Pthreads != software threads

The article states, pthreads are software threads "as opposed to hardware threads". That makes no sense, cause pthreads is a posix standard defining an interface. But the threads code can be backed by hardware threads (that's more likely) or by software threads. --2003:CB:770B:3875:E1D6:BF11:D281:23B2 (talk) 03:37, 1 August 2021 (UTC)