偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

計算機底層原理~CPU緩存一致性

開發(fā) 前端
由于在寫入操作之前,CPU 核心 1 需要先廣播 RFO 請求獲得獨占權(quán),在其它核心回應(yīng) ACK 之前,當(dāng)前核心只能空等待,這對 CPU 資源是一種浪費。因此,現(xiàn)代 CPU 會采用 “寫緩沖區(qū)” 機制:寫入指令放到寫緩沖區(qū)后并發(fā)送 RFO 請求后,CPU 就可以去執(zhí)行其它任務(wù),等收到 ACK 后再將寫入操作寫到 Cache 上。

CPU Cache知識回顧

CPU 的高速緩存,通??梢苑譃?L1、L2、L3 這樣的三層高速緩存,也稱為一級緩存、二級緩存、三級緩存。

L1 高速緩存訪問速度幾乎和寄存器一樣快,大小在幾十 KB 到幾百 KB 不等。每個 CPU 核心都有一塊屬于自己的 L1 高速緩存。

L2 高速緩存同樣每個 CPU 核心都有,但是 L2 高速緩存位置比 L1 高速緩存距離 CPU 核心 更遠(yuǎn),它大小比 L1 高速緩存更大,CPU 型號不同大小也就不同,通常大小在幾百 KB 到幾 MB 不等,訪問速度則更慢。

L3 高速緩存通常是多個 CPU 核心共用的,位置比 L2 高速緩存距離 CPU 核心 更遠(yuǎn),大小也會更大些,通常大小在幾 MB 到幾十 MB 不等。

cpu cache 結(jié)構(gòu)

CPU Cache 是由很多個 Cache Line 組成的,CPU Line 是 CPU 從內(nèi)存讀取數(shù)據(jù)的基本單位,而 CPU Line 是由各種標(biāo)志(Tag)+ 數(shù)據(jù)塊(Data Block)組成,你可以在下圖清晰的看到:

Cpu cache數(shù)據(jù)寫入的兩種方式

多核CPU同時工作的時候,每個核心都會從內(nèi)存中讀取一份數(shù)據(jù)并緩存到自己的Cache中,當(dāng)發(fā)生寫操作的時候,有兩種情況

  • 寫直達(dá):只要有數(shù)據(jù)寫入,都會把數(shù)據(jù)同時寫入內(nèi)存和 Cache 中,這種方式簡單直觀,但是性能就會受限于內(nèi)存的訪問速度;
  • 寫回:對于已經(jīng)緩存在 Cache 的數(shù)據(jù)的寫入,只需要更新其數(shù)據(jù)就可以,不用寫入到內(nèi)存,只有在需要把緩存里面的臟數(shù)據(jù)交換出去的時候,才把數(shù)據(jù)同步到內(nèi)存里,這種方式在緩存命中率高的情況,性能會更好;

寫直達(dá)

寫回

寫直達(dá)由于每次寫操作都會把數(shù)據(jù)寫回到內(nèi)存,而導(dǎo)致影響性能,于是為了要減少數(shù)據(jù)寫回內(nèi)存的頻率,就出現(xiàn)了寫回的方法。

  • 寫回策略會在每個 Cache 塊上增加一個 “臟(Dirty)” 標(biāo)記位 ,當(dāng)一個 Cache 被標(biāo)記為臟時,說明它的數(shù)據(jù)與內(nèi)存數(shù)據(jù)是不一致的;
  • 在寫入操作時,我們只需要修改 Cache 塊并將其標(biāo)記為臟,而不需要寫入內(nèi)存;
  • 那么,什么時候才將臟數(shù)據(jù)寫回內(nèi)存呢?—— 就發(fā)生在 Cache 塊被替換出去的時候:

寫回策略能夠減少寫回內(nèi)存的次數(shù),性能會比寫直達(dá)更高。當(dāng)然,寫回策略在讀取的時候,有可能不是純粹的讀取了,因為還可能會觸發(fā)一次臟 Cache 塊的寫入。

這里還有一個設(shè)計: 在目標(biāo)內(nèi)存塊不在 Cache 中時,寫直達(dá)策略會直接寫入內(nèi)存。而寫回策略會先把數(shù)據(jù)讀取到 Cache 中再修改 Cache 數(shù)據(jù),這似乎有點多余?其實還是為了減少寫回內(nèi)存的次數(shù)。雖然在未命中時會增加一次讀取操作,但后續(xù)重復(fù)的寫入都能命中緩存。否則,只要一直不讀取數(shù)據(jù),寫回策略的每次寫入操作還是需要寫入內(nèi)存。

寫回操作-寫入邏輯

寫回操作-讀取邏輯

實現(xiàn)緩存一致性

在單核 CPU 中,我們通過寫直達(dá)策略或?qū)懟夭呗员3至薈ache 與內(nèi)存的一致性。但是在多核 CPU 中,由于每個核心都有一份獨占的 Cache,就會存在一個核心修改數(shù)據(jù)后,兩個核心 Cache 不一致的問題。

舉個例子:

  • Core 1 和 Core 2 讀取了同一個內(nèi)存塊的數(shù)據(jù),在兩個 Core 都緩存了一份內(nèi)存塊的副本。此時,Cache 和內(nèi)存塊是一致的;
  • Core 1 執(zhí)行內(nèi)存寫入操作:

在寫直達(dá)策略中,新數(shù)據(jù)會直接寫回內(nèi)存,此時,Cache 和內(nèi)存塊一致。但由于之前 Core 2 已經(jīng)讀過這塊數(shù)據(jù),所以 Core 2 緩存的數(shù)據(jù)還是舊的。此時,Core 1 和 Core 2 不一致;

在寫回策略中,新數(shù)據(jù)會延遲寫回內(nèi)存,此時 Cache 和內(nèi)存塊不一致。不管 Core 2 之前有沒有讀過這塊數(shù)據(jù),Core 2 的數(shù)據(jù)都是舊的。此時,Core 1 和 Core 2 不一致。

  • 由于 Core 2 無法感知到 Core 1 的寫入操作,如果繼續(xù)使用過時的數(shù)據(jù),就會出現(xiàn)邏輯問題。

由于兩個核心的工作是獨立的,在一個核心上的修改行為不會被其它核心感知到,所以不管 CPU 使用寫直達(dá)策略還是寫回策略,都會出現(xiàn)緩存不一致問題。 所以,我們需要一種機制,將多個核心的工作聯(lián)合起來,共同保證多個核心下的 Cache 一致性,這就是緩存一致性機制。

寫傳播 & 事務(wù)串行化

緩存一致性機制需要解決的問題就是 2 點:

  • 特性 1 - 寫傳播(Write Propagation): 每個 CPU 核心的寫入操作,需要傳播到其他 CPU 核心;
  • 特性 2 - 事務(wù)串行化(Transaction Serialization): 各個 CPU 核心所有寫入操作的順序,在所有 CPU 核心看起來是一致。

總線嗅探 & 總線仲裁

寫傳播和事務(wù)串行化在 CPU 中是如何實現(xiàn)的呢?

寫傳播 - 總線嗅探: 總線除了能在一個主模塊和一個從模塊之間傳輸數(shù)據(jù),還支持一個主模塊對多個從模塊寫入數(shù)據(jù),這種操作就是廣播。要實現(xiàn)寫傳播,其實就是將所有的讀寫操作廣播到所有 CPU 核心,而其它 CPU 核心時刻監(jiān)聽總線上的廣播,再修改本地的數(shù)據(jù);

可以發(fā)現(xiàn),總線嗅探方法很簡單, CPU 需要每時每刻監(jiān)聽總線上的一切活動,但是不管別的核心的 Cache 是否緩存相同的數(shù)據(jù),都需要發(fā)出一個廣播事件,這無疑會加重總線的負(fù)載。

事務(wù)串行化 - 總線仲裁: 總線的獨占性要求同一時刻最多只有一個主模塊占用總線,天然地會將所有核心對內(nèi)存的讀寫操作串行化。如果多個核心同時發(fā)起總線事務(wù),此時總線仲裁單元會對競爭做出仲裁,未獲勝的事務(wù)只能等待獲勝的事務(wù)處理完成后才能執(zhí)行。

基于總線嗅探和總線仲裁,現(xiàn)代 CPU 逐漸形成了各種緩存一致性協(xié)議,例如 MESI 協(xié)議。

MESI協(xié)議

MESI 協(xié)議其實是 CPU Cache 的有限狀態(tài)機,一共有 4 個狀態(tài)(MESI 就是狀態(tài)的首字母):

  • M(Modified,已修改): 表明 Cache 塊被修改過,但未同步回內(nèi)存;
  • E(Exclusive,獨占): 表明 Cache 塊被當(dāng)前核心獨占,而其它核心的同一個 Cache 塊會失效;
  • S(Shared,共享): 表明 Cache 塊被多個核心持有且都是有效的;
  • I(Invalidated,已失效): 表明 Cache 塊的數(shù)據(jù)是過時的。

在 「獨占」 和 「共享」 狀態(tài)下,Cache 塊的數(shù)據(jù)是 “清” 的,任何讀取操作可以直接使用 Cache 數(shù)據(jù);

在 「已失效」 和 「已修改」 狀態(tài)下,Cache 塊的數(shù)據(jù)是 “臟” 的,它們和內(nèi)存的數(shù)據(jù)都可能不一致。在讀取或?qū)懭?“已失效” 數(shù)據(jù)時,需要先將其它核心 “已修改” 的數(shù)據(jù)寫回內(nèi)存,再從內(nèi)存讀??;

「獨占」和「共享」的差別在于,獨占狀態(tài)的時候,數(shù)據(jù)只存儲在一個 CPU 核心的 Cache 里,而其他 CPU 核心的 Cache 沒有該數(shù)據(jù)。這個時候,如果要向獨占的 Cache 寫數(shù)據(jù),就可以直接自由地寫入,而不需要通知其他 CPU 核心,因為只有你這有這個數(shù)據(jù),就不存在緩存一致性的問題了,于是就可以隨便操作該數(shù)據(jù)。

另外,在「獨占」?fàn)顟B(tài)下的數(shù)據(jù),如果有其他核心從內(nèi)存讀取了相同的數(shù)據(jù)到各自的 Cache ,那么這個時候,獨占狀態(tài)下的數(shù)據(jù)就會變成共享狀態(tài)。

那么,「共享」?fàn)顟B(tài)代表著相同的數(shù)據(jù)在多個 CPU 核心的 Cache 里都有,所以當(dāng)我們要更新 Cache 里面的數(shù)據(jù)的時候,不能直接修改,而是要先向所有的其他 CPU 核心廣播一個請求,要求先把其他核心的 Cache 中對應(yīng)的 Cache Line 標(biāo)記為「無效」?fàn)顟B(tài),然后再更新當(dāng)前 Cache 里面的數(shù)據(jù)。

事實上,完整的 MESI 協(xié)議更復(fù)雜,但我們沒必要記得這么細(xì)。我們只需要記住最關(guān)鍵的 2 點:

  • 關(guān)鍵 1 - 阻止同時有多個核心修改的共享數(shù)據(jù): 當(dāng)一個 CPU 核心要求修改數(shù)據(jù)時,會先廣播 RFO 請求獲得 Cache 塊的所有權(quán),并將其它 CPU 核心中對應(yīng)的 Cache 塊置為已失效狀態(tài);
  • 關(guān)鍵 2 - 延遲回寫: 只有在需要的時候才將數(shù)據(jù)寫回內(nèi)存,當(dāng)一個 CPU 核心要求訪問已失效狀態(tài)的 Cache 塊時,會先要求其它核心先將數(shù)據(jù)寫回內(nèi)存,再從內(nèi)存讀取。

提示: MESI 協(xié)議在 MSI 的基礎(chǔ)上增加了 E(獨占)狀態(tài),以減少只有一份緩存的寫操作造成的總線通信。

寫緩沖區(qū) & 失效隊列

MESI 協(xié)議保證了 Cache 的一致性,但完全地遵循協(xié)議會影響性能。 因此,現(xiàn)代的 CPU 會在增加寫緩沖區(qū)和失效隊列將 MESI 協(xié)議的請求異步化,以提高并行度:

  • 寫緩沖區(qū)(Store Buffer)

由于在寫入操作之前,CPU 核心 1 需要先廣播 RFO 請求獲得獨占權(quán),在其它核心回應(yīng) ACK 之前,當(dāng)前核心只能空等待,這對 CPU 資源是一種浪費。因此,現(xiàn)代 CPU 會采用 “寫緩沖區(qū)” 機制:寫入指令放到寫緩沖區(qū)后并發(fā)送 RFO 請求后,CPU 就可以去執(zhí)行其它任務(wù),等收到 ACK 后再將寫入操作寫到 Cache 上。

  • 失效隊列(Invalidation Queue)

由于其他核心在收到 RFO 請求時,需要及時回應(yīng) ACK。但如果核心很忙不能及時回復(fù),就會造成發(fā)送 RFO 請求的核心在等待 ACK。因此,現(xiàn)代 CPU 會采用 “失效隊列” 機制:先把其它核心發(fā)過來的 RFO 請求放到失效隊列,然后直接返回 ACK,等當(dāng)前核心處理完任務(wù)后再去處理失效隊列中的失效請求。

事實上,寫緩沖區(qū)和失效隊列破壞了 Cache 的一致性。

因為在未同步的情況下,程序可能會有多種執(zhí)行順序。這也是為什么Java里還需要volatile關(guān)鍵字,因為引入寫緩沖區(qū)或失效隊列后就變成弱數(shù)據(jù)一致性,不能滿足 強數(shù)據(jù)一致性: 保證在任意時刻任意副本上的同一份數(shù)據(jù)都是相同的,或者允許不同,但是每次使用前都要刷新確保數(shù)據(jù)一致,所以最終還是一致。

總結(jié)

  1. 在 CPU Cache 的三級緩存中,會存在 2 個緩存一致性問題:

縱向 - Cache 與內(nèi)存的一致性問題: 在修改 Cache 數(shù)據(jù)后,如何同步回內(nèi)存?

橫向 - 多核心 Cache 的一致性問題: 在一個核心修改 Cache 數(shù)據(jù)后,如何同步給其他核心 Cache?

  1. Cache 與內(nèi)存的一致性問題有 2 個策略:

寫直達(dá)策略: 始終保持 Cache 數(shù)據(jù)和內(nèi)存數(shù)據(jù)一致,在每次寫入操作中都會寫入內(nèi)存;

寫回策略: 只有在臟 Cache 塊被替換出去的時候?qū)懟貎?nèi)存,減少寫回內(nèi)存的次數(shù);

  1. 多核心 Cache 一致性問題需要滿足 2 點特性:

寫傳播(總線嗅探): 每個 CPU 核心的寫入操作,需要傳播到其他 CPU 核心;

事務(wù)串行化(總線仲裁): 各個 CPU 核心所有寫入操作的順序,在所有 CPU 核心看起來是一致。

  1. MESI 協(xié)議能夠滿足以上 2 點特性,通過 “已修改、獨占、共享、已失效” 4 個狀態(tài)實現(xiàn)了 CPU Cache 的一致性;
  2. 現(xiàn)代 CPU 為了提高并行度,會在增加 寫緩沖區(qū) & 失效隊列 將 MESI 協(xié)議的請求異步化, 從內(nèi)存的視角看就是指令重排,破壞了 CPU Cache 的一致性。也是為什么使用volatile關(guān)鍵字的原因
責(zé)任編輯:武曉燕 來源: 今日頭條
相關(guān)推薦

2022-12-14 08:23:30

2021-06-30 21:13:49

CPUCache數(shù)據(jù)

2020-05-12 10:43:22

Redis緩存數(shù)據(jù)庫

2020-10-26 19:25:23

CPU緩存Cache

2020-06-01 22:09:48

緩存緩存同步緩存誤用

2020-11-24 09:03:41

一致性MySQLMVCC

2022-03-22 09:54:22

Hash算法

2024-11-14 07:10:00

2023-11-20 08:10:55

處理器CPU緩存

2017-07-25 14:38:56

數(shù)據(jù)庫一致性非鎖定讀一致性鎖定讀

2018-08-08 15:51:44

Hash分布式算法

2020-09-10 16:50:32

mysqldump數(shù)據(jù)庫熱備

2024-04-10 10:34:34

Cache系統(tǒng)GPU

2019-10-16 00:06:08

CPU內(nèi)存存儲

2024-12-26 15:01:29

2020-11-12 10:53:36

volatile

2019-03-27 13:56:39

緩存雪崩穿透

2019-10-24 10:42:00

CPU內(nèi)存存儲器

2021-06-11 09:21:58

緩存數(shù)據(jù)庫Redis

2021-02-05 08:00:48

哈希算法?機器
點贊
收藏

51CTO技術(shù)棧公眾號