嵌入式C深入探索：內(nèi)存屏障與volatile的奧秘解析

正文

最有價值的寫在最前面

內(nèi)存屏障與 volatile 是高并發(fā)編程中比較常用的兩個技術(shù)，無鎖隊列的時候就會用到這兩項技術(shù)。然而這兩項技術(shù)涉及比較廣的基礎(chǔ)知識，所以比較難以理解，也比較不容易解釋清楚。關(guān)于內(nèi)存屏障和 volatile 網(wǎng)上有相當(dāng)多的資料，但是總感覺還是不夠系統(tǒng)和深入。當(dāng)然由于我自身水平有限，所以也不敢保證就能把這兩個概念說清楚。所以在文章的開始，先列舉一些我在學(xué)習(xí)過程中比較好的資料。

1.基本概念

https://blog.csdn.net/legend050709/article/details/109149321

這篇博客深入淺出的介紹了內(nèi)存屏障和volatile的概念，并且列舉了一些非常好的用例，可以直觀感受內(nèi)存屏障與volatile的作用。并且列舉了 linux 內(nèi)核中著名的無鎖隊列 kfifo 是如何使用內(nèi)存屏障的。

https://blog.csdn.net/liuhhaiffeng/article/details/106493224

這篇博客講解了 LOCK 前綴與內(nèi)存屏障的關(guān)系，LOCK 是實現(xiàn) CAS 操作的關(guān)鍵，所以弄清楚 LOCK 的作用也是非常有必要的。

《深入理解計算機系統(tǒng)》第三章、第四章、第六章

《深入理解計算機系統(tǒng)》是一本神書（本文后面都簡稱CSAPP），有多神相信就不用我介紹了。第三章介紹了while循環(huán)的機器指令，第四章有關(guān)于分支預(yù)測的相關(guān)知識，第六章有關(guān)于緩存的知識。

2.深入理解

《Memory Barriers: a Hardware View for Software Hackers》該文章深入淺出地講解了MESI的基本概念，MESI 引起的緩存可見性問題，從而引出了內(nèi)存屏障的作用，以及為什么要使用內(nèi)存屏障。該文章非常值得一讀。

這篇文章來自于《Is Parallel Programming Hard, And, If So, What Can You Do About It?》的附錄C。作者：Paul E.Mckenney

該書是一本開源的書，在https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html可以下載PDF。

該書的中文譯版為《深入理解并行編程》。譯者：謝寶友、魯陽

亞馬遜上有正版電子書~~

《Memory Ordering in Modern Microprocessors》該文章和上一篇是同一個作者。該文章對上一篇中第6部分的內(nèi)容進(jìn)行了更加詳細(xì)的說明。

3.Java volatile

在剛開始學(xué)習(xí)volatile和內(nèi)存屏障的時候，在網(wǎng)上搜到很多的資料都是講java實現(xiàn)的。volatile這個關(guān)鍵字在java和 CC++ 里面有非常大的區(qū)別，容易引起誤會。主要區(qū)別在于，java volatile 具有緩存同步的功能，而 CC++ 沒有這個功能，具體原因本文會簡單講下。詳細(xì)內(nèi)容參見B站馬士兵老師的課程。

https://www.bilibili.com/video/BV1R7411C7rf

4.無鎖隊列實踐

理論結(jié)合實踐，關(guān)于無鎖隊列的實現(xiàn)有幾篇文章值得一讀：

單生產(chǎn)者——單消費者模型

https://blog.csdn.net/linyt/article/details/53355355

講解kfifo的實現(xiàn)，kfifo是linux內(nèi)核實現(xiàn)的無鎖隊列，非常具有參考價值。

多對多模型

https://coolshell.cn/articles/8239.html

多個生產(chǎn)者和消費者，需要用到CAS操作。

個人認(rèn)為，如果把這些資料里的內(nèi)容都看懂了，后面的內(nèi)容其實也就可以不用看了，哈哈。好了，下面開始我個人對于內(nèi)存屏障和 volatile 的一些粗淺的見解。

volatile

關(guān)于 volatile 關(guān)鍵字 https://www.runoob.com/w3cnote/c-volatile-keyword.html 這里有詳細(xì)描述。主要是為了防止優(yōu)化編譯帶來的一些問題。注意：volatile 只作用于編譯階段，對運行階段沒有任何影響。

1.防止直接從寄存器中獲取全局變量的值

//disorder_test.c

#include?
#include?
#include?
#define?QUEUE_LEN?1??//為了測試方便?

typedef?struct
{
?int?m_flag;
?long?long?m_data;
}QUEUENODE,?LPQUEUENODE;

long?long?goods;
QUEUENODE?m_queue[QUEUE_LEN];

void*?Push(void*?param)
{
?long?long?data?=?*(long?long*)param;
?int?pos?=?data?%?QUEUE_LEN;
?
?while?(m_queue[pos].m_flag);
?
?m_queue[pos].m_data?=?data;
?m_queue[pos].m_flag?=?1;
?return?NULL;
}

void*?Pop(void*?param)
{
?int?pos?=?*(long?long*)param?%?QUEUE_LEN;
?
?while?(!m_queue[pos].m_flag);
?
?goods?=?m_queue[pos].m_data;
?m_queue[pos].m_flag?=?0;

?return?NULL;
}

int?main()
{
?long?long?i?=?1;
?memset(m_queue,?0,?sizeof(m_queue));

?pthread_t??pit1,?pit2;
??while?(1)
??{
???pthread_create(&pit1,?NULL,?&Push,?&i);
???pthread_create(&pit2,?NULL,?&Pop,?&i);
???//?wait?for?pthread?stop
???pthread_join(pit1,?NULL);
???pthread_join(pit2,?NULL);?

??printf("goods:%lld
",?goods);
??i++;
?}
}

如上面代碼所示，該代碼使用一個定長循環(huán)隊列，實現(xiàn)了一個生產(chǎn)者-消費者模型。該代碼中，只有一個生產(chǎn)者和一個消費者。QUEUENODE 定義了一個具體的商品。其中有兩個變量，m_flag 用于標(biāo)識隊列中對應(yīng)位置是否存在商品，m_flag 為 1 表示生產(chǎn)者已經(jīng)生產(chǎn)了商品，m_flag 為 0 表示商品還未被生產(chǎn)。m_data 表示商品具體的值。m_queue 為一個全局的循環(huán)隊列。

Push 函數(shù)向隊列中放入商品，在 push 前首先判斷指定位置是否存在商品，如果存在則等待（通過 while 自旋來實現(xiàn)），否則首先放入商品（為 m_data 賦值），再設(shè)置 m_flag 為 1。

Pop 函數(shù)用于從隊列中獲取商品，pop 之前先判斷指定位置是否存在商品，如果不存在則等待(通過while自旋來實現(xiàn))，否則首先取出商品（將 m_data 賦值給 goods），再設(shè)置 m_flag 為 0。

main 函數(shù)是一個死循環(huán)，每次開啟兩個線程，一個線程向隊列中 push 商品，一個線程從隊列中 pop 線程，然后等待兩個線程結(jié)束，最后打印出通過 pop 獲取到的商品的值，即 goods。

OK，現(xiàn)在用非優(yōu)化編譯編譯該代碼，并運行：

gcc?disorder_test.c?-o?disorder_test?-lpthread
./disorder_test

?

?

OK，看起來一切正常。

現(xiàn)在我們換成優(yōu)化編譯試試：

gcc?disorder_test.c?-O2?-o?disorder_test?-lpthread
./disorder_test

img

程序陷入了死循環(huán)…發(fā)生了什么？

現(xiàn)在我們來看看這段代碼的匯編，首先是非優(yōu)化編譯版本：

gcc?-S?disorder_test.c
cat?disorder_test.s

?

?

img

這里我們只標(biāo)注出最關(guān)鍵的部分，即 push 中的 while 循環(huán)。我們注意到，while 中每次循環(huán)都會執(zhí)行取值和運算操作，然后才執(zhí)行 testl 判斷。我們再來看看優(yōu)化版本。

gcc?-S?-O2?disorder_test.c
cat?disorder_test.s

img

這里就非常可怕了，可以看到 .L4 本身就是一個死循環(huán)，前面 testl 之后如果發(fā)現(xiàn)不滿足條件，則直接跳進(jìn)死循環(huán)。這是為什么？我們來看看 push 的代碼：

void*?Push(void*?param)
{
?long?long?data?=?*(long?long*)param;
?int?pos?=?data?%?QUEUE_LEN;
?while?(m_queue[pos].m_flag)
??;
?m_queue[pos].m_data?=?data;
?m_queue[pos].m_flag?=?1;
?return?NULL;
}

while循環(huán)會檢測m_queue[pos].m_flag，而在這個函數(shù)中，只有當(dāng)m_queue[pos].m_flag為0時，循環(huán)才會跳出，執(zhí)行l(wèi)ine7及之后的代碼，而在line8才會對m_flag進(jìn)行修改。所以編譯器認(rèn)為在循環(huán)的過程中，沒人會修改m_flag。既然沒有修改m_flag，只要m_flag一開始的值不為0，那么m_flag就是一個不會改變的值，當(dāng)然就是死循環(huán)！顯然編譯器并不知道另一個線程會執(zhí)行pop函數(shù)，而pop會修改m_flag的值。如果觀察pop的匯編代碼也會發(fā)現(xiàn)完全相同的優(yōu)化邏輯。

所以，在這種情況下，就需要程序員顯式的告訴編譯器，m_flag是一個會發(fā)生改變的值，所以不要嘗試做這樣的優(yōu)化。這就是volatile關(guān)鍵字?，F(xiàn)在我們給m_flag加上volatile關(guān)鍵字：

typedef?struct
{
?volatile?int?m_flag;
?long?long?m_data;
}QUEUENODE,?LPQUEUENODE;

再次優(yōu)化編譯并運行程序：

gcc?disorder_test.c?-O2?-o?disorder_test?-lpthread
./disorder_test

?

?

OK，一切正常！

現(xiàn)在我們再來看看匯編代碼：

現(xiàn)在每次循環(huán)都會執(zhí)行movl指令去獲取m_flag的值！一切都變得美好了。

2.防止指令亂序

volatile 的第二個作用就是防止編譯時產(chǎn)生的指令亂序。這個很簡單，有如下代碼：

//test.c
int?x,y,r;
void?f()
{
????x?=?r;
????y?=?1;
}

void?main()
{
????f();
}

這次，我們直接對比非優(yōu)化編譯與優(yōu)化編譯的匯編代碼。

非優(yōu)化編譯

優(yōu)化編譯

不難發(fā)現(xiàn)，優(yōu)化編譯的版本，交換了 x=r 和 y=1 的順序，先將 y 的值賦值為 1，再將 x 值賦值為 r。現(xiàn)在我們將 x，y， r 加上 volatile 關(guān)鍵字。

volatile?int?x,y,r;

再次查看匯編代碼：

指令順序和代碼順序一致。

在 https://www.runoob.com/w3cnote/c-volatile-keyword.html 介紹 volatile 時有這樣一段描述 “當(dāng)使用 volatile 聲明的變量的值的時候，系統(tǒng)總是重新從它所在的內(nèi)存讀取數(shù)據(jù)，即使它前面的指令剛剛從該處讀取過數(shù)據(jù)”。然而，實際情況真的是每次都從內(nèi)存中讀取數(shù)據(jù)么？其實這只是一個籠統(tǒng)的說法，更為準(zhǔn)確的說法應(yīng)該是，系統(tǒng)不會直接從寄存器中讀取 volatile 修飾的變量。因為，寄存器的讀寫性能遠(yuǎn)高于內(nèi)存，所以在CPU寄存器和內(nèi)存之前，通常有多級高速緩存。

相信大家都見過這樣一張著名的圖，不難發(fā)現(xiàn)，圖中，在內(nèi)存與寄存器之間，存在 L1、L2、L3 這樣三級緩存。所以指令在進(jìn)行訪存操作的時候，會首先逐級查看緩存中是否有對應(yīng)的數(shù)據(jù)，如果3級緩存有沒有期望的數(shù)據(jù)，才會訪問內(nèi)存。而通常在多核CPU中緩存是如下圖所示的這樣一種結(jié)構(gòu)：

每個 CPU core 都有自己獨立的 L1 和 L2 緩存，多個 core 共享一個L3緩存，多個 CPU 有各自的 L3 緩存，多個CPU 共享內(nèi)存。每個 core 都有自己獨立的 L1 和 L2 緩存，緩存可以獨立讀寫！這個就可怕了，因為這就存在不同 core 讀寫同一份數(shù)據(jù)的可能，如果不加任何限制，豈不天下大亂了？所以對于多核 CPU，需要一種機制來對緩存中的數(shù)據(jù)進(jìn)行同步。這也就是我們接下來要講的 MESI。

MESI

MESI 在《Memory Barriers: a Hardware View for Software Hackers》一文中有非常詳細(xì)的描述，這里只對一些關(guān)鍵問題進(jìn)行闡述。在描述 MESI 之前，我們先說明兩個重要的操作：

Load

Load是指CPU從Cache中加載數(shù)據(jù)。

Store

Store是指CPU將數(shù)據(jù)寫回Cache。

在《Memory Barriers: a Hardware View for Software Hackers》還有一個操作叫 write back（寫回），是指將Cache數(shù)據(jù)寫回內(nèi)存。

在 CSAPP 中，第4章講到指令的6個階段其中也有一個階段叫write back，這里是指將執(zhí)行階段的結(jié)果寫回到寄存器，這兩個概念不要混淆了。

MESI 是指緩存行的四種狀態(tài)：

I：invalid，最簡單的一種狀態(tài)，表示該緩存行沒有數(shù)據(jù)，顯然這也是緩存行的初始狀態(tài)。

S：shared，該緩存行中的數(shù)據(jù)被其他CPU共享。在shared狀態(tài)下，緩存行為只讀，不可以修改。

E：exclusive，該緩存行中的數(shù)據(jù)沒有被其他CPU共享，且緩存中的數(shù)據(jù)與內(nèi)存中保持一致。在exclusive狀態(tài)下，緩存行可以修改。

M：modified，該緩存行保存了唯一一份 up-to-date 的數(shù)據(jù)。即該緩存行中的數(shù)據(jù)沒有被其他CPU共享，且緩存行的數(shù)據(jù)與內(nèi)存不一致。

這四種狀態(tài)之間是可以互相轉(zhuǎn)換的，具體的轉(zhuǎn)換方式在《Memory Barriers: a Hardware View for Software Hackers》一文中也有非常詳細(xì)的描述（重要的是事情說三遍，這篇文章很重要！?。。＿@里我們只對部分狀態(tài)轉(zhuǎn)換加以說明。

I to S

緩存的初始狀態(tài)為I，即沒有數(shù)據(jù)。當(dāng)緩存行通過Read消息將數(shù)據(jù)加載進(jìn)來后，其狀態(tài)就變成了S。這個Read消息可以發(fā)送給其他緩存行，因為需要的數(shù)據(jù)可能在其他緩存行中，顯然當(dāng)前緩存行加載完數(shù)據(jù)后，該數(shù)據(jù)就被至少兩個緩存行共享，狀態(tài)就應(yīng)該為S。還有一種可能，就是沒有緩存行有這個數(shù)據(jù)，此時就需要從內(nèi)存中加載該數(shù)據(jù)，加載完成后，只有當(dāng)前緩存行有這個數(shù)據(jù)。這個狀態(tài)看起來更像是狀態(tài)E，但實際上這種情況狀態(tài)依然是S。我個人猜想，這或許是為了提升Read操作的性能，因為Read并沒有要修改數(shù)據(jù)的意思，所以沒必要去區(qū)分Read之后數(shù)據(jù)是否真的被共享了。

S to E

我們前面說到，S狀態(tài)的緩存行是只讀的，如果想要修改怎么辦？直接改可以么？當(dāng)然不行，如果直接改那么就會出現(xiàn)同一份數(shù)據(jù)在不同的緩存行中值不同！這顯然是不可接受的。所以如果一個CPU希望修改處于S狀態(tài)的緩存行里面的數(shù)據(jù)，就需要向其他CPU發(fā)invalidate消息，收到invalidate消息的CPU需要將對應(yīng)緩存行的狀態(tài)改為invalid，即相應(yīng)緩存行就不再持有這份數(shù)據(jù)了，改完之后需要回一個invalidate acknowledge消息。當(dāng)發(fā)出invalidate消息的CPU收到所有的invalidate acknowledge后就現(xiàn)在這份數(shù)據(jù)有他獨占了，于是將相應(yīng)緩存行的狀態(tài)改了為E。

不難看出由S狀態(tài)轉(zhuǎn)變?yōu)镋狀態(tài)是比較耗時的，因為需要等待所有CPU都回送invalidate acknowledge消息。

E to M

狀態(tài)E到狀態(tài)M的轉(zhuǎn)變就非常簡單了，因為緩存已經(jīng)處于E也就是獨占狀態(tài)了，此時當(dāng)前CPU就可以修改這個緩存行的值，也就是前面提到過的Store操作。Store操作之后緩存行的狀態(tài)就由之前的E變?yōu)榱薓。

其實從MESI的規(guī)定，不難看出，MESI確保了緩存的一致性，即不會存在共享同一個數(shù)據(jù)的兩個緩存行中數(shù)據(jù)值不一致。數(shù)據(jù)在修改之前總是需要等待所有共享了該數(shù)據(jù)的其他緩存行失效。然而對于CPU來講，這樣的等待是漫長且低效的。于是工程師們?yōu)榱颂岣咝蔬M(jìn)行了一些優(yōu)化，而正是這樣的優(yōu)化引入了緩存可見性的問題。

Store Buffer

a?=?1;?
b?=?a?+?1;?
assert(b?==?2);

如上面代碼所示。首先 line2 的加法運算要使用到 line1 中的變量a，所以兩行代碼是存在數(shù)據(jù)相關(guān)性的，那么編譯器不會嘗試交換指令順序。我們假設(shè)現(xiàn)在變量 a 在 CPU1 中，變量 b 在 CPU0 中，且初始值均為0。假設(shè)現(xiàn)在 CPU0 要執(zhí)行上述代碼，根據(jù)前面 MESI 的規(guī)定，上述代碼的執(zhí)行順序如下：

CPU0 執(zhí)行 a= 1

在執(zhí)行過程中，發(fā)現(xiàn) a 并不在 CPU0 中，所以需要發(fā)送 read 消息讀取 a 的值。而讀取之后又需要修改 a 的值，就需要發(fā)送 invalidate 消息。這兩個消息可以用 read invalidate 消息來代替。CUP1 在收到 read invalidate 消息后會發(fā)送相應(yīng)緩存行中 a 的值，并且 invalidate 該緩存行，然后發(fā)送 invalidate acknowledge 消息。

CPU0需要等待CPU1傳回的a值以及invalidate acknowledge，然后才能修改a的值，最后將對應(yīng)緩存行的狀態(tài)改為M。

CPU0執(zhí)行b=a+1

此時a，b均在CPU0的中，所以直接執(zhí)行就好。

CPU0執(zhí)行assert(b == 2)

顯然此時b的值一定為2。

這個流程的關(guān)鍵在于 CPU0 需要等待 CPU1 回傳的消息，而前面說過這樣的等待很耗時。

從 a = 1; 這行代碼不難發(fā)現(xiàn)，不論 CPU1 回傳給 CPU0 的值是什么，我們會將 a 的值最終修改為1，那么我們真正需要等待的只是 invalidate acknowledge。那么我們是不是可以先將 a = 1; 這條指令緩存起來，繼續(xù)執(zhí)行后面的操作，等收到 invalidate acknowledge 之后再來真正修改 a 的值呢？答案是肯定的，如下圖所示：

Store Buffer的問題

在 CPU 和 cache 之前，引入了一個稱為 store buffer 的緩存?，F(xiàn)在，我們在執(zhí)行 a=1 時，如果需要等待 invalidate acknowledge，那么就先將 a=1 寫入這個 store buffer ，然后繼續(xù)執(zhí)行后面的代碼，等到收到 invalidate acknowledge 再將 store buffer 中的值寫入緩存。好了，那么現(xiàn)在問題來了。有了store buffer之后，前面代碼就可以是這樣的一種執(zhí)行順序。

CPU0 執(zhí)行a= 1

在執(zhí)行過程中，發(fā)現(xiàn)a并不在CPU0中，所以CPU0向CPU1發(fā)送read invalidate消息。然后將a = 1寫入store buffer。繼續(xù)執(zhí)行后面的代碼。

CPU0執(zhí)行b=a+1

在執(zhí)行過程中，CPU0 收到了 CPU1 傳回的 a 值0。CPU0 將 a 的值加載到緩存中，然后執(zhí)行 a+1，于是得到了 b 的值1。此時CPU0 到了invalidate acknowledged，于是使用 store buffer 中的條目，將 cache 中 a 的值修改為1。然而已經(jīng)沒有什么卵用了。

CPU0執(zhí)行assert(b == 2)

顯然此時 b 的值一定為 1。

上述問題違反了 CPU 的 self-consistency，即每個CPU需要保證自身的操作看起來與代碼順序一致。于是對于CPU進(jìn)行了改進(jìn)，同一個 CPU 的 store 操作可以直接作用于后面的 load 操作。所以 CPU0 在 load a 時發(fā)現(xiàn) store buffer 中 a 的正確值應(yīng)該是1，于是使用這個值進(jìn)行后面的運算。

這個改進(jìn)可以解決 CPU 的 self-consistency 問題，但是卻解決不了 global memory ordering 問題。有如下代碼：

void?foo(void)?
{?
????a?=?1;?
????b?=?1;?
}

void?bar(void)?
{?
????while?(b?==?0)?
?????continue;?
????assert(a?==?1);?
}

?

?

假設(shè)，a，b初始值為0。a 在CPU1中且為 exclusive 狀態(tài)，b 在 CPU0 中且為 exclusive 狀態(tài)，CPU0 執(zhí)行 foo()，CPU1 執(zhí)行 bar()。情況如下：

CPU0執(zhí)行 a=1

在執(zhí)行過程中發(fā)現(xiàn)a不在CPU0的緩存中，于是發(fā)送 read invalidate給 CPU1，然后將 a=1 寫入 store buffer。繼續(xù)執(zhí)行。

CPU1 執(zhí)行 whie(b == 0)

在執(zhí)行過程中發(fā)現(xiàn) b 不在 CPU1 的緩存行中，于是發(fā)送 read 給CPU0。

CPU0執(zhí)行b=1

由于 b 在 CPU0 中且為獨占，于是這句話直接就執(zhí)行成功了。

CPU0 收到 CPU1 的 read 消息

于是將b的值1送回給CPU1，并且將緩存行狀態(tài)修改為shared。

CPU1 收到 CPU0 的 read ack

于是得知 b 的值為1，從而跳出循環(huán)，繼續(xù)向后執(zhí)行。

CPU1執(zhí)行 assert(a == 1);

注意，此時 CPU1 還未收到 read invalidate 消息。由于 a 在CPU1中依然是獨占，所以 CPU1 直接從緩存中獲取到 a 的值0。于是 assert 失敗。（注意，a = 1 是存在于 CPU0 的 store buffer 中，而不是 CPU1。）

CPU1 收到 CPU0 的read invalidate

CPU1向CPU0傳回a的值0，以及invalid ack。

CPU0收到CPU1的值以及invalid ack

CPU0 使用 store buffer 中的條目，將 cache 中 a 的值修改為1。

內(nèi)存屏障

造成上述問題的核心是 a=1; 還沒有被所有CPU的可見的時候，b=1; 已經(jīng)被所有CPU都可見了。而 a=1 不可見的原因是 store buffer 中的數(shù)據(jù)還沒有應(yīng)用到緩存行中。解決這個問題可以有兩種思路：

store buffer 中還有數(shù)據(jù)時暫停執(zhí)行。

store buffer中還有數(shù)據(jù)時把后續(xù)的 store 操作也寫入 store buffer。

這里就要用到內(nèi)存屏障了。修改上述代碼如下：

void?foo(void)?
{?
????a?=?1;?
????smp_mb();??//內(nèi)存屏障
????b?=?1;?
}

void?bar(void)?
{?
????while?(b?==?0)?continue;?
????assert(a?==?1);?
}

按照思路1，CPU0 執(zhí)行到 line4 時，發(fā)現(xiàn) store buffer 中有 a=1，于是暫停執(zhí)行，直到 store buffer 中的數(shù)據(jù)應(yīng)用到cache中，再繼續(xù)執(zhí)行 b=1。這樣便沒問題了。

按照思路2，CPU0 執(zhí)行到 line4 時，發(fā)現(xiàn) store buffer中有 a=1，于是將該條目做一個標(biāo)記（標(biāo)記store buffer中的所有當(dāng)前條目）。在執(zhí)行b=1時，發(fā)現(xiàn)store buffer中有一個帶標(biāo)記的條目，于是將b=1也寫入store buffer，這樣b=1對于CPU1也就不可見了。只有當(dāng)代標(biāo)記的條目應(yīng)用于緩存之后，后續(xù)條目才可以應(yīng)用于緩存。

這相當(dāng)于只有當(dāng)標(biāo)記條目都應(yīng)用于緩存后，后續(xù)的store操作才能進(jìn)行。

通過這兩種方式就很好的解決了緩存可見性問題。仔細(xì)觀察這個流程，其實感覺有點數(shù)據(jù)庫事務(wù)的意思，哈哈，技術(shù)果然都是互通的。

不難發(fā)現(xiàn)，內(nèi)存屏障限制了CPU的執(zhí)行流程，所以同樣會有一定的性能損失，但是顯然不滿足正確性任何性能都是扯淡。

Invalidate Queue

在使用了內(nèi)存屏障之后，store buffer中就可能堆積很多條目，因為必須等到帶有標(biāo)記的條目應(yīng)用到緩存行。store buffer的大小也是有限的，當(dāng)store buffer滿了之后便又會出現(xiàn)前面提到的性能問題。所以還有什么優(yōu)化的方式么？

MESI 性能問題的核心是 Invalidate ack 耗時太長。而這個耗時長的原因是，CPU必須確保cache真的被invalidate了才會發(fā)送 Invalidate ack。而在CPU忙時顯然會增加 Invalidate ack 的延遲。那么我們是不是也可以像store buffer那樣把invalidate 消息緩存起來呢？這個顯然也是可以的。于是，工程師們又增加了 invalidate queue 來緩存 invalidate 消息。

CPU收到invalidate消息后，不用真正等到 cache invalidate，只需要將 invalidate 消息存放到 Invalidatae Queue 中就可以發(fā)送 invalidate ack了。而收到 invalidate ack 的 CPU 就可以將 store buffer 中相應(yīng)的條目應(yīng)用到 cache。

Invalidate Queue的問題

前面store buffer的經(jīng)驗告訴我們，天下沒有免費的午餐。Invalid Buffer的引入同樣也會帶來問題。我們再來看看前面的代碼：

void?foo(void)?
{?
????a?=?1;?
????smp_mb();??//內(nèi)存屏障
????b?=?1;?
}

void?bar(void)?
{?
????while?(b?==?0)?continue;?
????assert(a?==?1);?
}

假設(shè)，a，b初始值為0。a在CPU0和CPU1之前共享，狀態(tài)為shared，b在CPU0中且為exclusive狀態(tài)，CPU0執(zhí)行foo()，CPU1執(zhí)行bar()。情況如下：

CPU0執(zhí)行a=1

在執(zhí)行過程中發(fā)現(xiàn)a的狀態(tài)為shared，于是發(fā)送invalidate給CPU1，然后將a=1寫入store buffer。繼續(xù)執(zhí)行。

CPU1執(zhí)行whie(b == 0)

在執(zhí)行過程中發(fā)現(xiàn)b不在CPU1的緩存行中，于是發(fā)送read給CPU0。

CPU1收到invalidate消息

CPU1將invalidate存入invalidate queue，然后立即返回invalidate ack。

CPU0收到invalidate ack

CPU0將store buffer中的條目應(yīng)用到cache上，此時a的值為1。

CPU0執(zhí)行b=1;

由于b在CPU0上獨占，且store buffer為空，所以直接就執(zhí)行成功了。

CPU0收到CPU1的read消息

于是將b的值1送回給CPU1，并且將緩存行狀態(tài)修改為shared。

CPU1收到CPU0的read ack

于是得知b的值為1，從而跳出循環(huán)，繼續(xù)向后執(zhí)行。

CPU1執(zhí)行assert(a == 1);

注意，此時invalidate消息在invalidate queue中，所以CPU1并未對相應(yīng)緩存執(zhí)行ivalidate操作，所以此時原始的緩存行對于CPU1是可見的，于是獲取到了a的原始值0，導(dǎo)致assert失敗。

這個問題的核心很簡單，就是在獲取緩存行的時候沒有檢查invalidate queue。解決方法也很簡單，使用內(nèi)存屏障。

void?foo(void)?
{?
????a?=?1;?
????smp_mb();??//內(nèi)存屏障
????b?=?1;?
}

void?bar(void)?
{?
????while?(b?==?0)?continue;?
????smp_mb();??//內(nèi)存屏障
????assert(a?==?1);?
}

使用內(nèi)存屏障后，會標(biāo)記store buffer中的所有當(dāng)前條目，只有當(dāng)所有標(biāo)記的條目都應(yīng)用于緩存后，后續(xù)的load操作才能進(jìn)行。

When a given CPU executes a memory barrier, it marks all the entries currently in its invalidate queue, and forces any subsequent load to wait until all marked entries have been applied to the CPU’s cache.

所以在加上內(nèi)存屏障之后，在執(zhí)行 assert(a == 1)之前需要先將invalidate queue中的條目應(yīng)用于緩存行。所以在執(zhí)行 a== 1 時，CPU1 會發(fā)現(xiàn) a 不在 CPU1 的緩存，從而給 CPU0 發(fā)送read消息，獲得 a 的值1，最終assert(a == 1); 成功。

其實在這里內(nèi)存屏障還有一個非常重要的作用，因為a==1并不一定要等 b != 0時才會執(zhí)行。這又是為什么？

while (b == 0) continue;是一個條件循環(huán)，條件循環(huán)的本質(zhì)是條件分支+無條件循環(huán)（IF+LOOP）。在執(zhí)行條件分支時，為了更好的利用指令流水，有一種被稱作分支預(yù)測的機制。所以實際執(zhí)行的時候可能會假定條件分支的值為FALSE，從而提前執(zhí)行 assert(a == 1);

關(guān)于while循環(huán)和指令流水可以參見CSAPP的第三、第四章。

三種內(nèi)存屏障

smp_mb(); 會同時作用于store buffer和invalidate queue，所以被稱為全屏障。在上述代碼中，我們不難發(fā)現(xiàn)一個問題，foo()函數(shù)只會用到store buffer，而bar()函數(shù)只會用到invalidate queue。根據(jù)這個特點，除了全屏障之外通常還有讀屏障(smp rmb())和寫屏障(smp rmb())。讀屏障只作用于invalidate queue，而寫屏障只作用于store buffer。所以上述代碼還可以修改為下面的方式：

void?foo(void)?
{?
????a?=?1;?
????smp_wmb();??//寫屏障
????b?=?1;?
}

void?bar(void)?
{?
????while?(b?==?0)?continue;?
????smp_rmb();??//讀屏障
????assert(a?==?1);?
}

內(nèi)存屏障的使用

什么時候需要使用內(nèi)存屏障

其實，在我們?nèi)粘５拈_發(fā)中，尤其是應(yīng)用研發(fā)。我們根本就用不上內(nèi)存屏障？這是為什么？

雖然內(nèi)存屏障用不上，但是在并發(fā)編程里面鎖的概念卻無處不在！信號量、臨界區(qū)等等。然而這些技術(shù)的背后都是內(nèi)存屏障。道理其實很簡單，種種的線程進(jìn)程同步的手段，實際上都相當(dāng)于鎖。對于臨界資源的訪問，我們總是希望先上鎖，再訪問。所以顯然，我們肯定不希望加鎖后的操作由于CPU的種種優(yōu)化跑到了加鎖前去執(zhí)行。那么這種時候自然就需要使用內(nèi)存屏障。

所以，對于使用了 線程進(jìn)程 同步的手段進(jìn)行加鎖的代碼，不用擔(dān)心內(nèi)存屏障的問題。只有為了提高并發(fā)性采用的很多無鎖設(shè)計，才需要考慮內(nèi)存屏障的問題。

當(dāng)然，對于單線程開發(fā)和單核CPU也不用擔(dān)心內(nèi)存屏障的問題。

補充：鎖是如何實現(xiàn)的

通常情況下，鎖都是基于一種叫做CAS（compare-and-swap）的操作實現(xiàn)的。CAS的代碼如下：

static?__inline__?int
tas(volatile?slock_t?*lock)
{
?register?slock_t?_res?=?1;

__asm__?__volatile__(
?"?lock???
"
?"?xchgb?%0,%1?
"

:??"+q"(_res),?"+m"(*lock)
:??/*?no?inputs?*/
:??"memory",?"cc");
?return?(int)?_res;
}

其中：xchgb 就是實現(xiàn) CAS 的指令，而在 xchgb 之前有一個 lock 前綴，這個前綴的作用是鎖總線，達(dá)到的效果就是內(nèi)存屏障的效果。這也就是為什么使用了鎖就不用擔(dān)心內(nèi)存屏障的問題了。而 JAVA 對于內(nèi)存屏障的底層實現(xiàn)其實就是用的這個lock。

參考資料：

postgresql源代碼中自旋鎖的實現(xiàn)，函數(shù)調(diào)用順序：SpinLockAcquire > S_LOCK > s_lock > TAS_SPIN > TAS > tas

https://blog.csdn.net/liuhhaiffeng/article/details/106493224

https://www.bilibili.com/video/BV1R7411C7rf

實際案例

linux 內(nèi)核的無鎖隊列 kfifo 就使用了內(nèi)存屏障。這里主要說明 __kfifo_put() 函數(shù)和 __kfifo_get()。__kfifo_put() 用于向隊列中寫入數(shù)據(jù)，__kfifo_get() 用于從隊列中獲取數(shù)據(jù)

/**
?*?__kfifo_put?-?puts?some?data?into?the?FIFO,?no?locking?version
?*?@fifo:?the?fifo?to?be?used.
?*?@buffer:?the?data?to?be?added.
?*?@len:?the?length?of?the?data?to?be?added.
?*
?*?This?function?copies?at?most?@len?bytes?from?the?@buffer?into
?*?the?FIFO?depending?on?the?free?space,?and?returns?the?number?of
?*?bytes?copied.
?*
?*?Note?that?with?only?one?concurrent?reader?and?one?concurrent
?*?writer,?you?don't?need?extra?locking?to?use?these?functions.
?*/
unsigned?int?__kfifo_put(struct?kfifo?*fifo,
????unsigned?char?*buffer,?unsigned?int?len)
{
?unsigned?int?l;

?len?=?min(len,?fifo->size?-?fifo->in?+?fifo->out);

?/*
??*?Ensure?that?we?sample?the?fifo->out?index?-before-?we
??*?start?putting?bytes?into?the?kfifo.
??* line19是讀操作，line30之后是寫操作（向隊列中寫數(shù)據(jù)），所以需要使用全屏障（隔離讀和寫）。
??*/

?smp_mb();

?/*?first?put?the?data?starting?from?fifo->in?to?buffer?end?*/
?l?=?min(len,?fifo->size?-?(fifo->in?&?(fifo->size?-?1)));
?memcpy(fifo->buffer?+?(fifo->in?&?(fifo->size?-?1)),?buffer,?l);

?/*?then?put?the?rest?(if?any)?at?the?beginning?of?the?buffer?*/
?memcpy(fifo->buffer,?buffer?+?l,?len?-?l);

?/*
??*?Ensure?that?we?add?the?bytes?to?the?kfifo?-before-
??*?we?update?the?fifo->in?index.
??* line34是寫操作，line44也是寫操作，所以使用寫屏障（隔離寫和寫）。
??*/

?smp_wmb();

?fifo->in?+=?len;

?return?len;
}
EXPORT_SYMBOL(__kfifo_put);

/**
?*?__kfifo_get?-?gets?some?data?from?the?FIFO,?no?locking?version
?*?@fifo:?the?fifo?to?be?used.
?*?@buffer:?where?the?data?must?be?copied.
?*?@len:?the?size?of?the?destination?buffer.
?*
?*?This?function?copies?at?most?@len?bytes?from?the?FIFO?into?the
?*?@buffer?and?returns?the?number?of?copied?bytes.
?*
?*?Note?that?with?only?one?concurrent?reader?and?one?concurrent
?*?writer,?you?don't?need?extra?locking?to?use?these?functions.
?*/
unsigned?int?__kfifo_get(struct?kfifo?*fifo,
????unsigned?char?*buffer,?unsigned?int?len)
{
?unsigned?int?l;

?len?=?min(len,?fifo->in?-?fifo->out);

?/*
??*?Ensure?that?we?sample?the?fifo->in?index?-before-?we
??*?start?removing?bytes?from?the?kfifo.
??* line18讀操作，line29是讀操作（從隊列中讀數(shù)據(jù)），所以需要使用讀屏障（隔離讀和讀）。
??*/

?smp_rmb();

?/*?first?get?the?data?from?fifo->out?until?the?end?of?the?buffer?*/
?l?=?min(len,?fifo->size?-?(fifo->out?&?(fifo->size?-?1)));
?memcpy(buffer,?fifo->buffer?+?(fifo->out?&?(fifo->size?-?1)),?l);

?/*?then?get?the?rest?(if?any)?from?the?beginning?of?the?buffer?*/
?memcpy(buffer?+?l,?fifo->buffer,?len?-?l);

?/*
??*?Ensure?that?we?remove?the?bytes?from?the?kfifo?-before-
??*?we?update?the?fifo->out?index.
??* line33是讀操作，line43是寫操作，所以需要使用全屏障（隔離讀和寫）。
??*/

?smp_mb();

?fifo->out?+=?len;

?return?len;
}
EXPORT_SYMBOL(__kfifo_get);

kfifo 的詳細(xì)內(nèi)容，請查閱相關(guān)資料，這里不再贅述。

深入理解

我們不難發(fā)現(xiàn)，不論是 __kfifo_put還是 __kfifo_get 都使用了兩次內(nèi)存屏障。我們以 __kfifo_put 為例子來觀察下這兩個內(nèi)存屏障，在 __kfifo_put 中，第一次使用內(nèi)存屏障是 line27 的 smp_mb 第二次是 line42 的 smp_wmb?，F(xiàn)在思考一個問題，這兩個內(nèi)存屏障可以省略么？為了解決這個問題，我們需要思考，如果省略了內(nèi)存屏障會有什么問題？

省略 smp_mb

省略 smp_mb 會出現(xiàn)優(yōu)化編譯導(dǎo)致的指令亂序么？

smp_mb 位于 line19 和 line30 之間，如果省略了 smp_mb，在優(yōu)化編譯的情況下 line19 的代碼會和 lin30 的代碼交換順序么？不會！因為這兩行代碼有數(shù)據(jù)相關(guān)性，line30 會使用 line19 計算出的 len 值。

省略 smp_mb 會造成緩存可見性問題么？

會！fifo->out由 __kfifo_get函數(shù)修改。如果省略smp_mb在執(zhí)行l(wèi)ine30之前，__kfifo_get對于fifo->out的修改對于__kfifo_put可能不可見。不可見會造成什么后果？在__kfifo_get中會增加fifo->out的長度，如果這個增加不可見，那么line19的len值就會小一些（相對于可見情況），也就是說可以put的數(shù)據(jù)就少一些，除此之外并沒有什么其他后果。kfifo隊列依然可以正常工作。

綜上所述，如果省略smp_mb，會造成一些性能問題，但不會有正確性問題。

省略smp_wmb

省略smp_wmb會出現(xiàn)優(yōu)化編譯導(dǎo)致的指令亂序么？

smp_wmb位于line34和line44之間，如果省略了smp_wmb，在優(yōu)化編譯的情況下line34的代碼會和lin44的代碼交換順序么？有可能！因為這兩行代碼沒有數(shù)據(jù)相關(guān)性，是相互獨立的代碼。

省略smp_wmb會造成緩存可見性問題么？

會！line43對于fifo->out的修改可能比line33的memcpy更早的被其他CPU感知！這就相當(dāng)于，數(shù)據(jù)都還沒有拷貝進(jìn)去，就告訴別人數(shù)據(jù)已經(jīng)準(zhǔn)備好，你來取吧！所以如果這個時候另一個CPU運行的__kfifo_get函數(shù)，不幸的相信了這句鬼話，就會取出之前的老數(shù)據(jù)。這個是存在正確性問題的！

綜上所述，如果省略smp_wmb，會引起正確性問題。

驗證

好了，我們可以驗證下上面的說法。上面闡述的代碼是linux新版本的kfifo。我們可以看看老版本的kfifo是如何實現(xiàn)的。在linux-3.0.10內(nèi)核代碼中，可以找到老版本的kfifo。其中最重要的兩個函數(shù)是__kfifo_in（對應(yīng)__kfifo_put）和__kfifo_out（對應(yīng)__kfifo_get）。為了方便閱讀，我將__kfifo_in中的函數(shù)調(diào)用直接展開，如下圖：

不難發(fā)現(xiàn)，老版的 __kfifo_in 就只使用了一個內(nèi)存屏障，在 memcpy 和修改 fifo->in 之間，這也就是我們之前說的那個不可以省略的 smp_wmb。

審核編輯：黃飛

?