Multiple threads: MESI-CPU Cache Consistency Protocol

Source: Internet
Author: User

MESI (Modified Exclusive Shared Or Invalid) (also known as the Illinois Protocol, because the agreement was presented by Illinois State University) is a widely used cache consistency protocol that supports writeback policies, which are applied to the Intel Pentium series of CPUs, as described in "support the Efficient Write-back Cache In addition to the Write-through cache previously used by the Intel 486 processor "

Status in the Mesi protocol

Each cache row (Caceh line) in the CPU is marked with 4 states (using an additional two bit (bit) representation):

M: Modified (Modified)

The cache row is cached only in the cache of the CPU and is modified (dirty), which is inconsistent with the data in main memory, which needs to be written back to the main storage at some point in the future (allowing the other CPU to read the corresponding memory in main storage).

When it is written back to main memory, the state of the cache line becomes the exclusive (exclusive) state.

E: Exclusive (Exclusive)

The cache line is cached only in the cache of the CPU, which is unmodified (clean), consistent with the data in main memory. This state can become shared at any moment when the memory is read by another CPU.

Similarly, when the CPU modifies the contents of the cache line, the state can become a modified state.

S: Shared

This state means that the cache row may be cached by multiple CPUs, and the data in each cache is consistent with the main memory data (clean), when there is a CPU that modifies the cache line,

The cache line can be invalidated (into an invalid state (Invalid)) in other CPUs.

I: Invalid (Invalid)

The cache is not valid (there may be other CPUs that have modified the cache line).

Mesi state transition Diagram


The reciprocal transitions between States can also be represented using the following table.

TD style= "BORDER-WIDTH:1PX; Border-color: #aaaaaa; Border-style:solid; Padding:0.2em; " > TD style= "BORDER-WIDTH:1PX; Border-color: #aaaaaa; Border-style:solid; Padding:0.2em; " > TD style= "BORDER-WIDTH:1PX; Border-color: #aaaaaa; Border-style:solid; Padding:0.2em; " >
& nbsp;   m   e   s   i 
& nbsp m 
& nbsp e 
& nbsp s 
I

Operation:

In a typical system, there may be several caches (in multicore systems, each core will have its own cache) to share the main memory bus, each corresponding CPU will issue read and write requests, and the purpose of the cache is to reduce the number of times the CPU reads and writes shared memory.

A cache can satisfy the CPU's read request In addition to the invalid state, and a invalid cache line must be read from main memory (into the S or e state) to satisfy that CPU's read request.

A write request can only be executed if the cache line is in the M or e state, and if the cache row is in the S state, the cache row in the other cache must first become the invalid state (also not allow different CPUs to modify the same cache row at the same time, even if the data in different locations in the cache row is not allowed). This action is often done in a broadcast manner, for example:Request for Ownership (RFO)

The cache can invalidate a non-M-state cache line at any time, or become a invalid state, while the cache line of an M-state must first be written back to main memory.

A cache line in the M state must always listen for all attempts to read the cache line relative to the main memory, which must be deferred until the cache is written back to main memory and the state becomes the S state.

A cache line in the S state must also listen to other caches to invalidate the cache line or to exclusive access to the cache row and invalidate the cache row (Invalid).

A cache line in the E state must also listen for other cached rows in the cache read memory, and once this is done, the cache line needs to become the S state.

Always accurate for M and e states, they are consistent with the actual state of the cache line. While the S state may be inconsistent, if a cache is invalidated by a cache line in the S state, and the other cache may actually have exclusive access to the cache row, the cache does not upsize the cache row to the E state because other caches do not broadcast notifications that they have invalidated the cache line. Also, because the cache does not hold the number of copy of the cache row, there is no way to determine whether or not you have exclusive access to the cache row, even with this notification.

From the above, the E-state is a speculative optimization: If a CPU wants to modify a cache line in the S state, the bus transaction needs to change all of the cache rows to the invalid state, and the cache for the E-state does not need to use a bus transaction.

Multiple threads: MESI-CPU Cache Consistency Protocol

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.