Editing MESI protocol (section)

=== Memory Barriers ===
MESI in its naive, straightforward implementation exhibits two particular performance issues. First, when writing to an invalid cache line, there is a long delay while the line is fetched from other CPUs. Second, moving cache lines to the invalid state is time-consuming. To mitigate these delays, CPUs implement store buffers and invalidate queues.<ref>{{Cite book|title=The Cache Memory Book|last=Handy|first=Jim|publisher=Morgan Kaufmann|year=1998|isbn=9780123229809}}</ref>

==== Store Buffer ====
A store buffer is used when writing to an invalid cache line.  As the write will proceed anyway, the CPU issues a read-invalid message (hence the cache line in question and all other CPUs' cache lines that store that memory address are invalidated) and then pushes the write into the store buffer, to be executed when the cache line finally arrives in the cache.

A direct consequence of the store buffer's existence is that when a CPU commits a write, that write is not immediately written in the cache. Therefore, whenever a CPU needs to read a cache line, it first scans its own store buffer for the existence of the same line, as there is a possibility that the same line was written by the same CPU before but hasn't yet been written in the cache (the preceding write is still waiting in the store buffer). Note that while a CPU can read its own previous writes in its store buffer, other CPUs ''cannot see those writes'' until they are flushed to the cache - a CPU cannot scan the store buffer of other CPUs.

==== Invalidate Queues ====

With regard to invalidation messages, CPUs implement invalidate queues, whereby incoming invalidate requests are instantly acknowledged but not immediately acted upon. Instead, invalidation messages simply enter an invalidation queue and their processing occurs as soon as possible (but not necessarily instantly).  Consequently, a CPU can be oblivious to the fact that a cache line in its cache is actually invalid, as the invalidation queue contains invalidations that have been received but haven't yet been applied.  Note that, unlike the store buffer, the CPU can't scan the invalidation queue, as that CPU and the invalidation queue are physically located on opposite sides of the cache.

As a result, memory barriers are required.  A ''store barrier'' will flush the store buffer, ensuring all writes have been applied to that CPU's cache.  A ''read barrier'' will flush the invalidation queue, thus ensuring that all writes by other CPUs become visible to the flushing CPU. Furthermore, memory management units do not scan the store buffer, causing similar problems. This effect is visible even in single threaded processors.<ref>{{Cite book | doi = 10.1007/978-3-319-12154-3_8| chapter = Store Buffer Reduction with MMUs| title = Verified Software: Theories, Tools and Experiments| volume = 8471| pages = 117| series = Lecture Notes in Computer Science| year = 2014| last1 = Chen | first1 = G. | last2 = Cohen | first2 = E. | last3 = Kovalev | first3 = M. | isbn = 978-3-319-12153-6}}</ref>