Cache一致性協議之MOESI
MOESI協議引入了一個O(Owned)狀態，並在MESI協議的基礎上，進行了重新定義了S狀態，而E、M和I狀態和MESI協議的對應狀態相同。
- O位。O位爲1表示在當前Cache 行中包含的數據是當前處理器系統最新的數據拷貝，而且在其他CPU中一定具有該Cache行的副本，其他CPU的Cache行狀態爲S。如果主存儲器的數據在多個CPU的Cache中都具有副本時，有且僅有一個CPU的Cache行狀態爲O，其他CPU的Cache行狀態只能爲S。與MESI協議中的S狀態不同，狀態爲O的Cache行中的數據與存儲器中的數據並不一致。
- S位。在MOESI協議中，S狀態的定義發生了細微的變化。當一個Cache行狀態爲S時，其包含的數據並不一定與存儲器一致。如果在其他CPU的Cache中不存在狀態爲O的副本時，該Cache行中的數據與存儲器一致；如果在其他CPU的Cache中存在狀態爲O的副本時，Cache行中的數據與存儲器不一致。
在一個處理器系統中，主設備(CPU或者外部設備)進行存儲器訪問時，將試圖從存儲器系統(主存儲器或者其他CPU的Cache)中獲得最新的數據拷貝。如果該主設備訪問的數據沒有在本地命中時，將從其他CPU的Cache中獲取數據，如果這些數據仍然沒有在其他CPU的Cache中命中，主存儲器將提供數據。外設設備進行存儲器訪問時，也需要進行Cache共享一致性。
在MOESI模型中，“Probe Read”表示主設備從其他CPU中獲取數據拷貝的目的是爲了讀取數據；而“Probe Write”表示主設備從其他CPU中獲取數據拷貝的目的是爲了寫入數據；“Read Hit”和“Write Hit”表示主設備在本地Cache中獲得數據副本；“Read Miss”和“Write Miss”表示主設備沒有在本地Cache中獲得數據副本；“Probe Read Hit”和“Probe Write Hit”表示主設備在其他CPU的Cache中獲得數據副本。
本節爲簡便起見，僅介紹CPU進行存儲器寫和與O狀態相關的Cache行狀態遷移，CPU進行存儲器讀的情況相對較爲簡單，請讀者自行分析這個過程。
當CPU對一段存儲器進行寫操作時，如果這些數據在本地Cache中命中時，其狀態可能爲E、S、M或者O。
- 狀態爲E或者M時，數據將直接寫入到Cache中，並將狀態改爲M。
- 狀態爲S時，數據將直接寫入到Cache中，並將狀態改爲M，同時其他CPU保存該數據副本的Cache行狀態將從S或者O遷移到I(Probe Write Hit)。
- 狀態爲O時，數據將直接寫入到Cache中，並將狀態改爲M，同時其他CPU保存該數據副本的Cache行狀態將從S遷移到I(Probe Write Hit)。
當CPU A對一段存儲器進行寫操作時，如果這些數據沒有在本地Cache中命中時，而在其他CPU，如CPU B的Cache中命中時，其狀態可能爲E、S、M或者O。其中CPU A使用CPU B在同一個Cache共享域中。
- Cache行狀態爲E時，CPU B將該Cache行狀態改爲I；而CPU A將從本地申請一新的個Cache行，將數據寫入，並該Cache行狀態更新爲M。
- Cache行狀態爲S時，CPU B將該Cache行狀態改爲I，而且具有同樣副本的其他CPU的Cache行也需要將狀態改爲I；而CPU A將從本地申請一個Cache行，將數據寫入，並該Cache行狀態更新爲M。
- Cache行狀態爲M時，CPU B將原Cache行中的數據回寫到主存儲器，並將該Cache行狀態改爲I；而CPU A將從本地申請一個Cache行，將數據寫入，並該Cache行狀態更新爲M。
- Cache行狀態爲O時，CPU B將原Cache行中的數據回寫到主存儲器，並將該Cache行狀態改爲I，具有同樣數據副本的其他CPU的Cache行也需要將狀態從S更改爲I；CPU A將從本地申請一個Cache行，將數據寫入，並該Cache行狀態更新爲M。
Cache行狀態可以從M遷移到O。例如當CPU A讀取的數據從CPU B中命中時，如果在CPU B中Cache行的狀態爲M時，將遷移到O，同時CPU B將數據傳送給CPU A新申請的Cache行中，而且CPU A的Cache行狀態將被更改爲S。
當CPU讀取的數據在本地Cache中命中，而且Cache行狀態爲O時，數據將從本地Cache獲得，並不會改變Cache行狀態。如果CPU A讀取的數據在其他Cache中命中，如在CPU B的Cache中命中而且其狀態爲O時，CPU B將該Cache行狀態保持爲O，同時CPU B將數據傳送給CPU A新申請的Cache行中，而且CPU A的Cache行狀態將被更改爲S。
在某些應用場合，使用MOESI協議將極大提高Cache的利用率，因爲該協議引入了O狀態，從而在發送Read Hit的情況時，不必將狀態爲M的Cache回寫到主存儲器，而是直接從一個CPU的Cache將數據傳遞到另外一個CPU。目前MOESI協議在AMD和RMI公司的處理器中得到了廣泛的應用。
Intel提出了另外一種MESI協議的變種，即MESIF協議，該協議與MOESI協議有較大的不同，也遠比MOESI協議複雜，該協議由Intel的QPI(QuickPath Interconnect)技術引入，其主要目的是解決“基於點到點的全互連處理器系統”的Cache共享一致性問題，而不是“基於共享總線的處理器系統”的Cache共享一致性問題。
在基於點到點互連的NUMA(Non-Uniform Memroy Architecture)處理器系統中，包含多個子處理器系統，這些子處理器系統由多個CPU組成。如果這個處理器系統需要進行全機Cache共享一致性，該處理器系統也被稱爲ccNUMA(Cache Cohenrent NUMA)處理器系統。MESIF協議主要解決ccNUMA處理器結構的Cache共享一致性問題，這種結構通常使用目錄表，而不使用總線監聽處理Cache的共享一致性。
MESIF協議引入了一個F(Forware)狀態。在ccNUMA處理器系統中，可能在多個處理器的Cache中存在相同的數據副本，在這些數據副本中，只有一個Cache行的狀態爲F，其他Cache行的狀態都爲S。Cache行的狀態位爲F時，Cache中的數據與存儲器一致。
當一個數據請求方讀取這個數據副本時，只有狀態爲F的Cache行，可以將數據副本轉發給數據請求方，而狀態位爲S的Cache不能轉發數據副本。從而MESIF協議有效解決了在ccNUMA處理器結構中，所有狀態位爲S的Cache同時轉發數據副本給數據請求方，而造成的數據擁塞。
在ccNUMA處理器系統中，如果狀態位爲F的數據副本，被其他CPU拷貝時，F狀態位將會被遷移，新建的數據副本的狀態位將爲F，而老的數據副本的狀態位將改變爲S。當狀態位爲F的Cache行被改寫後，ccNUMA處理器系統需要首先Invalidate狀態位爲S其他的Cache行，之後將Cache行的狀態更新爲M。
獨立地研究MESIF協議並沒有太大意義，該協議由Boxboro-EX處理器系統[1]引入，目前Intel並沒有公開Boxboro-EX處理器系統的詳細設計文檔。MESIF協議僅是解決該處理器系統中Cache一致性的一個功能，該功能的詳細實現與QPI的Protocal Layer相關，QPI由多個層次組成，而Protocal Layer是QPI的最高層。
對MESIF協議QPI互連技術有興趣的讀者，可以在深入理解“基於目錄表的Cache一致性協議”的基礎上，閱讀Robert A. Maddox, Gurbir Singh and Robert J. Safranek合著的書籍“Weaving High Performance Multiprocessor Fabric”以瞭解該協議的實現過程和與QPI互連技術相關的背景知識。
值得注意的是，MESIF協議解決主要的問題是ccNUMA架構中SMP子系統與SMP子系統之間Cache一致性。而在SMP處理器系統中，依然需要使用傳統的MESI協議。Nehelem EX處理器也可以使用MOESI協議進一步優化SMP系統使用的Cache一致性協議，但是並沒有使用該協議。
爲簡化起見，本章假設處理器系統使用MESI協議進行Cache共享一致性，而不是MOESI協議或者MESIF協議。
