mesi協議的約束範圍？

01-22

會不會存在這種情況，
CPUA和CPUB同時執行a=a+1，CPUA先執行，此時a的值在CPUB的緩存行里，值為0
1.CPUA發送read invalidate，得到a的值同時收到ack，緩存行狀態變成E。

2.CPUA將a的值讀入寄存器，執行a+1操作過程中，緩存行狀態還是E。
3.CPUB開始執行操作，發現a不在自己的cache，發送read invalidate。
4.CPUB得到a存儲在緩存行里的值，並且收到ack，然後執行a=a+1,並將a值寫入緩存，狀態為M。
5.此時CPUA執行完a=a+1，發現緩存行狀態為 I，然後發送read invalidate，得到獨佔權，修改a的值為1。

我的意思也就是說，只有當CPU寫入緩存行的時候，緩存行的狀態才會發生改變，變為M，而在他之前a+1的操作已經完成，並且 +1 和寫入之間並不具有原子性。CPU同樣不保證a+1操作的期間，a在本地緩存的狀態是獨佔的，只要求他在讀a的值的時候是獨佔的就可以。
一致性協議只約束緩存，只要求在邏輯執行單元和緩存交互數據的那一個時間點達成一致就可以，他並不能約束之後CPU里的操作到底做了什麼。

mesi是cache coherence protocol，管的範圍僅限於cache coherent 在如題中的arithmetic instruction中由於沒有cache read/write 所以mesi不適用。

我根據你大概的想法，想表達的是CPUA和CPUB同時執行

mov eax ,[edi]

add eax,#0x1

mov [edi],eax

初始條件：此時a的值在CPUB的緩存行里，值為0，此時在b中cache line 是E，CPUA中沒有該cacheline，CPUA先執行

1.CPUA發送PrRd，A的cacheline狀態變成S。因為該緩存已在CPUB中，所以是S，PrRd是不發invalidate的

2.CPUA將a的值讀入寄存器，執行a=a+1操作過程中，緩存行狀態還是S。a=1

3.CPUB開始執行操作，發現a在自己的cache中，還是E。執行a=a+1，得出a=1

4.CPUA 進行PrWr cacheline 變M 並發送BusRdx invalidate CPUB中的cacheline

5.此時CPUA執行完str 存入cacheline。該值為1。CPUB中cacheline 為I。

6.CPU執行str，從新fetch那條cacheline，變成S，再把a=1存進去。

你的理解是對的，cache coherence protocol只約束cache operation，在CPU裡面的操作是不涉及cache的話mesi是不適用的。

可以發現及時兩個cpu都做了a=a+1，最後cacheline裡面存的還是1。如果希望最後存的是2，那麼就涉及memory consistency。軟體lock定一個地址然後按照需求來安排執行順序。

關於為什麼不讓硬體來管理memory consistency，我以前轉發過一篇論文，但是我後來潛水的時候全部刪了。現在不在農企了，找不到那個扔我一臉論文的小姐姐了。

伸展閱讀：（其實只是Wikipedia）

MESI protocol - Wikipedia

Consistency model

Memory Consistency Models

如某些答案，這個RMW的行為並不是cache coherency的範疇，而是memory consistency的範疇。體系結構的概念一定要清晰。

在CC範疇步驟5的行為就會錯誤。

真實情況可以參考LINUX的的共享變數處理，如果CPU支持atomic指令（包括ARM的exclusive指令），OS會調用atomic指令完成RMW，這類指令可以保證RMW的過程中CACHE Coherency緯度狀態不變。

如果CPU不支持atomic指令，則會採用spinlock機制，即額外用鎖鎖定訪問許可權，讓RMW操作對象為獨享方式完成。

瀉藥。 4和5那個流程就不對。read invalidation是會被fwd到cpu寄存器的。你說的情況不會發生。