[導讀]↓推薦關注↓本文是《C并發(fā)編程》一文的姊妹篇。將著重介紹C11標準引入的內存模型。前言在《C并發(fā)編程》一文中，我們已經介紹了C11到C17在并發(fā)編程方面的新增API。借助那篇文章中的知識，你應該已經可以開發(fā)一個完善的C并發(fā)系統(tǒng)。這對絕大部分人來說，是足夠的了。但在一些情況下，我們...
↓推薦關注↓
本文是《C 并發(fā)編程》一文的姊妹篇。將著重介紹C 11標準引入的內存模型。img img img img img
除了上面這些，還有更多關于整形類型的原子類型，詳見：cppreference std::atomic[15]。“原子操作”正如其名稱所示：該操作要么是執(zhí)行完了，要么是沒有執(zhí)行，從任何一個線程中，都無法觀察到中間狀態(tài)。以原子讀操作為例：如果有其他線程進行了原子寫操作，那么原子讀操作，要么獲取到的是修改前的值，要么是修改后的，不會是修改了一半的值。而非原子類型就不一樣了。如果嘗試修改非原子類型對象，其他線程可能看到的既不是修改前的值，也不是修改后的值。關于這一點，在C 并發(fā)編程中，我們就看到了非原子類型所引起的問題。需要注意的是，所有原子類型都不支持拷貝和賦值。因為該操作涉及了兩個原子對象：要先從另外一個原子對象上讀取值，然后再寫入另外一個原子對象。而對于兩個不同的原子對象上單一操作不可能是原子的。不同的原子類型包含了不同的原子操作，下表將原子類型分為四類，并列出了它們所支持的操作（為了簡潔，列名上類名中的
本文是《C 并發(fā)編程》一文的姊妹篇。將著重介紹C 11標準引入的內存模型。
前言
在《C 并發(fā)編程》一文中，我們已經介紹了C 11到C 17在并發(fā)編程方面的新增API。借助那篇文章中的知識，你應該已經可以開發(fā)一個完善的C 并發(fā)系統(tǒng)。這對絕大部分人來說，是足夠的了。但在一些情況下，我們可能還需要走得更遠。回顧一下，上文中提到的知識是以互斥體為中心的。為了避免競爭條件，是保證任何時候只有一個線程可以進入臨界區(qū)。這就存在兩個問題：- 可能會出現死鎖
- 并發(fā)的效率不夠
關于C 內存模型
2004年，Java 5.0引入了適用于多線程環(huán)境的內存模型[2]：JSR-133[3]。但C 直到2011標準才引入了內存模型。Java內存模型在很大程度上影響了C 內存模型，但后者走得更遠。因為它允許開發(fā)者打破順序一致性（Sequential Consistency，我們會在下文中講解），以獲得更好的控制。之所以這么做是因為C 是一門系統(tǒng)編程語言，它的設計意圖之一就是：不需要另外一個更底層的語言，而是直接提供給開發(fā)者以”接近機器“的方式編程。即便大多數程序員不用在意內存模型，但是當你以“接近機器”的方式工作時，了解這些原理就很重要了。內存模型是多線程環(huán)境能夠可靠工作的基礎，因為內存模型需要對多線程環(huán)境的運作細節(jié)進行完備的定義。簡單來講，可以認為內存模型是一種契約。它定義一套操作手法以及這些操作手法背后的詳細含義。開發(fā)者利用這套操作完成數據的同步以避免競爭條件，而系統(tǒng)（包括：編譯器，操作系統(tǒng)和處理器）保證執(zhí)行的邏輯符合內存模型對于相關操作的定義 – 即實現契約。內存模型主要包含了下面三個部分：- 元子操作：顧名思義，這類操作一旦執(zhí)行就不會被打斷，你無法看到它的中間狀態(tài)，它要么是執(zhí)行完成，要么沒有執(zhí)行。
- 操作的局部順序：一系列的操作不能被亂序。
- 操作的可見性：定義了對于共享變量的操作如何對其他線程可見。
為什么需要內存模型？
在C 11標準出來之前，C 環(huán)境沒有多線程的概念。編譯器和處理器認為系統(tǒng)中只有一個執(zhí)行流。引入了多線程之后，情況就會變得非常復雜。這是因為：現代計算機系統(tǒng)為了加快執(zhí)行效率，自動的包含了很多的優(yōu)化。這些優(yōu)化雖然保證了在單線程環(huán)境下不破壞原來的邏輯。但是一旦到了多線程之后，情況就不一樣了。事實上，開發(fā)者編寫的代碼和最終運行的程序往往會存在較大的差異，而運行結果與開發(fā)者預想一致，只是一種“假象”罷了。之所以會產生差異，原因主要來自下面三個方面：- 編譯器優(yōu)化
- CPU out-of-order執(zhí)行
- CPU Cache不一致性
Memory Reorder
以下面這段偽代碼為例：X?=?0,?Y?=?0;
Thread?1:?
X?=?1;?//?①
r1?=?Y;?//?②
Thread?2:?
Y?=?1;
r2?=?X;
你可能會覺得，在這個程序執(zhí)行完成之后，r1和r2怎么都不可能同時為0。但事實并非如此[4]。這是因為“Memory Reorder”的存在，“Memory Reorder”包含了編譯器和處理器兩種類型的亂序。編譯器優(yōu)化
以gcc為例，該編譯器提供了-o參數來控制非常多的優(yōu)化選項[6]。以下面這段代碼為例：int?A,?B;
void?foo()
{
????A?=?B? ?1;
????B?=?0;
}
在編譯優(yōu)化后，可能會變成下面這樣：int?A,?B;
void?foo()
{
????int?temp?=?B;
????B?=?0;
????A?=?temp? ?1;
}
請注意，編譯器只要保證：在單線程環(huán)境下，執(zhí)行的結果和原先一樣就可以了。所以，這樣做是可以的。對于編譯器來說，它知道的是：當前線程中，數據的讀寫以及數據之間的依賴關系。但是，編譯器并不知道哪些數據是在線程間共享，而且是有可能會被修改的。這就需要開發(fā)者在軟件層面做好控制。對于編譯器的亂序優(yōu)化來說，開發(fā)者并非完全不能控制。編譯器會提供稱之為內存柵欄（Memory Barrier）[7]的工具給開發(fā)者，讓開發(fā)者告訴編譯器：這部分代碼編譯的時候不能亂序。gcc的內存柵欄寫法如下：int?A,?B;
void?foo()
{
????A?=?B? ?1;
????asm?volatile(""?:::?"memory");
????B?=?0;
}
Out-of-order執(zhí)行
不僅僅是編譯器，處理器也可能會亂序執(zhí)行指令。下面是維基上給出的一張表格，列出了不同類型的CPU可能會執(zhí)行的亂序類別。- Weak vs. Strong Memory Models[9]
- This Is Why They Call It a Weakly-Ordered CPU[10]
- A Tutorial Introduction to the ARM and POWER Relaxed Memory Models[11]
- x86-TSO: A Rigorous and Usable Programmer’s Model for x86 Multiprocessors[12]
fence指令：lfence?(asm),?void?_mm_lfence(void)
sfence?(asm),?void?_mm_sfence(void)
mfence?(asm),?void?_mm_mfence(void)
由此提醒我們：如果我們只以單線程的思維來開發(fā)并發(fā)系統(tǒng)，一旦引入了Memory Reorder之后就可能會發(fā)生問題。例如：以上面的A，B兩個變量為例，在編譯器將其亂序后，雖然對于當前線程是沒問題的。但是如果在此時剛好有另外一個線程使用這兩個變量，并且依賴于它們的更新順序，那么就會出現問題。Cache Coherency
事情還不只這么簡單?，F代的主流CPU幾乎都會包含多個核以及多級Cache，下圖是我的MacBook Pro上的CPU Cache信息。對象和內存位置
C 內存模型中的基本存儲單位是字節(jié)。一個字節(jié)至少足夠大，能夠包含基本執(zhí)行字符集的任何成員以及Unicode UTF-8編碼形式的八位代碼單元，并且由連續(xù)的位序列組成。C 中所有數據都是由對象組成的。這里的對象包括了簡單基本類型（如int和double），也包括了指針類型（如my_class*）。當然，也包括各種class定義的類的對象。無論是什么類型，一個對象均包含了一個或多個內存位置。每個內存位置一定是下面兩種情況中的一種：- 標量類型（Scalar Type）的對象，標量類型包括下面幾種：
- 數字類型：整數或者浮點數
T *指針類型- 枚舉類型
- 指向成員的指針
nullptr_t- 相鄰位域（Bit field）[13]的最大序列
位域
位域聲明具有以“位”為單位的明確大小的類數據成員。相鄰的位域成員可以打包成共享和跨過各個字節(jié)。例如這樣：struct?S?{
?//?三位的無符號位域，
?//?允許值為?0...7
?unsigned?int?b?:?3;
};
位域的值必須大于等于0。值0比較特殊，它僅允許使用在無名位域上。并且它具有特殊含義：它指定類定義中的下個位域將始于分配單元的邊界。由此，請看一下下面的例子：struct?S?{
????char?a;?????????//?內存位置?#1
????int??b?:?5;?????//?內存位置?#2
????int??c?:?11,????//?內存位置?#2?（接續(xù)，相鄰位域占用同一個內存位置）
???????????:?0,?????//?無名位域，分隔了下一個位域
?????????d?:?8;?????//?內存位置?#3?（由于存在0值無名位域，這里是一個新的內存位置）
????struct?{
????????int?ee?:?8;?//?內存位置?#4
????}?e;
}?obj;
可以看到，這個結構包含了4個內存位置。之所以介紹內存位置，是因為這與內存模型密切相關。如果多個線程各自訪問的是不同的內存位置，那么就不會有什么問題。但是，如果它們同時訪問了相同的內存位置，那就要小心了。**當多個線程訪問同一個內存位置，并且其中只要有一個線程包含了寫操作，如果這些訪問沒有一致的修改順序，那么結果就是未定義的。**也就是說：可能會發(fā)生bug。修改順序
我們已經知道，C 中的數據都是由對象組成。一個對象包含了若干個內存位置。每個對象從初始化開始，直到最終銷毀，在其生命周期的范圍內，對它進行的訪問必須有一個確定的修改順序，這個順序包含了所有線程的訪問操作。雖然程序的每一次運行，這個順序可能是不一樣的（例如：CPU資源的變化，調度器的影響），但是針對其中具體的某一次來說，必須有一個“一致的順序”，這個順序要被所有的線程認可，并且可見。例如：一旦某個線程修改了一個數據，這個操作必須要讓所有線程知道，在修改操作之后，所有線程都應該得到修改后的值。從數據類型的角度來說，有兩種情況：- 對于原子類型（見下文）：由編譯器保證數據的同步。
- 對于非原子類型：由開發(fā)者保證。
關系術語
下面先來介紹C 內存模型中的幾個關系術語。sequenced-before
sequenced-before是一種單線程上的關系，這是一個非對稱，可傳遞的成對關系。對于兩個操作A和B，如果A sequenced-before B，則A的執(zhí)行應當在B的前面，并且A執(zhí)行后的結果B也能看到，它引入了一個局部有序性。同一個線程中的多個語句之間就是sequenced-before關系，例如：int?i?=?7;?//?①
i ;???????//?②
這里的 ① sequenced-before ② 。但是同一個語句中的多個子表達式上沒有這個關系的。特別極端的，對于下面這個語句：i?=?i ? ?i;
由于等號右邊的兩個子表達式無法確定先后關系，因此這個語句的行為是未定義的。這意味著，你永遠不應該寫這樣的代碼。happens-before
happens-before關系是sequenced-before關系的擴展，因為它還包含了不同線程之間的關系。如果A happens-before B，則A的內存狀態(tài)將在B操作執(zhí)行之前就可見，這就為線程間的數據訪問提供了保證。同樣的，這是一個非對稱，可傳遞的關系。如果A happens-before B，B happens-before C。則可推導出A happens-before C。synchronizes-with
synchronizes-with描述的是一種狀態(tài)傳播（propagate）關系。如果A synchronizes-with B，則就是保證操作A的狀態(tài)在操作B執(zhí)行之前是可見的。下文中我們將看到，原子操作的acquire-release具有synchronized-with關系。除此之外，對于鎖和互斥體的釋放和獲取可以達成synchronized-with關系，還有線程執(zhí)行完成和join操作也能達成synchronized-with關系。最后，借助 synchronizes-with 可以達成 happens-before 關系。原子類型與原子操作
要理解內存模型，首先需要掌握C 11提供的原子類型（atomic types）和原子操作（atomic operation）。原子類型不是一個類，而是一系列類，它們都位于關于volatile和原子類型：Java和C 都有volatile關鍵字。但同樣的關鍵字在不同的語言中有著不同的含義。Java中的volatile和C 的原子類型是類似的含義。而C 中的volatile是禁止編譯器對這個變量進行優(yōu)化。
| 類型別名 | 類型定義 |
|---|---|
| atomic_bool | std::atomic |
| atomic_char | std::atomic |
| atomic_schar | std::atomic |
| atomic_uchar | std::atomic |
| atomic_int | std::atomic |
| atomic_uint | std::atomic |
| atomic_short | std::atomic |
| atomic_ushort | std::atomic |
| atomic_long | std::atomic |
| atomic_ulong | std::atomic |
| atomic_llong | std::atomic |
| atomic_ullong | std::atomic |
| atomic_char16_t | std::atomic |
| atomic_char32_t | std::atomic |
| atomic_wchar_t | std::atomic |
atomic用#代替）。| 函數 | #_flag | #_bool | 指針類型 | 整形類型 | 說明 |
|---|---|---|---|---|---|
| test_and_set | Y | 將flag設為true并返回原先的值 | |||
| clear | Y | 將flag設為false | |||
| is_lock_free | Y | Y | Y | 檢查原子變量是否免鎖 | |
| load | Y | Y | Y | 返回原子變量的值 | |
| store | Y | Y | Y | 通過一個非原子變量的值設置原子變量的值 | |
| exchange | Y | Y | Y | 用新的值替換，并返回原先的值 | |
| compare_exchange_weak compare_exchange_strong | Y | Y | Y | 比較和改變值 | |
| fetch_add, = | Y | Y | 增加值 | ||
| fetch_sub, -= | Y | Y | 減少值 | ||
| , -- | Y | Y | 自增和自減 | ||
| fetch_or, |= | Y | 求或并賦值 | |||
| fetch_and,
本站聲明： 本文章由作者或相關機構授權發(fā)布，目的在于傳遞更多信息，并不代表本站贊同其觀點，本站亦不保證或承諾內容真實性等。需要轉載請聯(lián)系該專欄作者，如若文章內容侵犯您的權益，請及時聯(lián)系本站刪除。
換一批
延伸閱讀
|
下載文檔
