滅哈哈，想了多半年的時間，終于明白多核編程的實質(zhì)了～!@#$%^&*(

塑料袋

基本原理概括為兩句話：
1) CPU2若看到CPU1執(zhí)行了某條指令，則必可看到CPU1中這條指令之前的所有指令。
2) CPU3若看到CPU2執(zhí)行了某條指令，而此時CPU2若看到CPU1執(zhí)行了某條指令，則CPU3必可看到CPU1中的這條指令。該原則遞歸。

是不是很有bbjmmj的味道？哈哈。


不過俺覺得這就是人腦對多核編程的第一個感性認(rèn)識，抽象概括出來就是順序模型。所以才有了亂序模型中的內(nèi)存屏障。

《super-scalar processor design》
《Memory Consistency Models for Shared-Memory Multiprocessors》
《arm architecture referece manual     armv7A》
documentation/memory-barrier.txt
........................................................

  這些書都是在反復(fù)的討論這兩句話，滅哈哈。

smalloc

"看到"是指引用其結(jié)果沒?
CPU1中這條指令之前的所有指令--這個之前是指CPU1上已經(jīng)運行的指令(這個沒多大問題,如果每CPU讀寫總是按一定序), 還是指即使存在亂序的情況下, 在亂序之前的指令序都能被"看到".

zhujiang73

基本原理概括為兩句話：
1) CPU2若看到CPU1執(zhí)行了某條指令，則必可看到CPU1中這條指令之前的所有指令。
2 ...
塑料袋 發(fā)表于 2011-09-10 11:53

    一個 CPU 執(zhí)行一個線程，看什么看。

塑料袋

沒人來踩。抬杠都沒機(jī)會。唉

zylthinking

沒人來踩。抬杠都沒機(jī)會。唉
塑料袋 發(fā)表于 2011-09-10 17:47

不踩， 求科普

塑料袋

"看到"是指引用其結(jié)果沒?
CPU1中這條指令之前的所有指令--這個之前是指CPU1上已經(jīng)運行的指令(這個沒多大問題,如果每CPU讀寫總是按一定序), 還是指即使存在亂序的情況下, 在亂序之前的指令序都能被"看到".

smalloc 發(fā)表于 2011-09-10 15:28

這里是說的順序模型。不過這個是最重要的。

因為亂序模型是根據(jù)順序模型來設(shè)計的，mb()的作用，就是搞了個順序一致的點，mb()前后的指令表現(xiàn)為順序一致。   


什么叫“看到”，雖然很多個文檔中定義了到底什么叫“看到”，不過以arm architecture reference manual中定義的最為標(biāo)準(zhǔn)。

什么時候可以認(rèn)為load指令被看到？  對同一地址執(zhí)行store時，不影響load的返回結(jié)果，即為load被看到

什么時候可以認(rèn)為store指令被看到？  對同一地址執(zhí)行l(wèi)oad時，將返回store的值，即為store被看到



雖然原理看起來很簡單，不過reorder buffer，load / store unit，store buffer，cache............的設(shè)計，均是以此為出發(fā)點。


一個例子，執(zhí)行mb()時需要將CPU1的各個讀寫請求通過MESI發(fā)給別的CPU，然后等待這些讀寫請求完成，即這些請求的應(yīng)答reply后，才叫mb()執(zhí)行完成。

但是為什么對于讀請求，需要這個讀操作確實在其他CPU的cache中完成，才能發(fā)回reply； 但是對于寫請求，僅僅是將invalidate request掛在其他CPU的incoming queue上，不等invalidate在其他CPU的cache中完成，就可以發(fā)回來reply？？？

對于上邊這種情況，有一個基本的設(shè)計原則：對于本CPU而言，
1) 從其他CPU發(fā)過來的invalidate request，
2) 從其他CPU發(fā)過來的的read reply，invalidate reply

這兩類數(shù)據(jù)包之間，一定不能亂序；但是本類數(shù)據(jù)包內(nèi)部，可以亂序。 這樣的話：

處理其他CPU發(fā)來的read replay之前，則必然已經(jīng)處理了其他CPU發(fā)來的invalidate request。即看到其他CPU的一個store操作時，則必然可看到這個store之前的所有store。

處理其他CPU發(fā)來的invalidate replay之前，則必然已經(jīng)處理了其他CPU發(fā)來的invalidate request。即看到其他CPU的一個load操作時，則必然可看到這個load之前的所有store。

smalloc

回復(fù) 6# 塑料袋


    記得LZ曾說過 構(gòu)架是精髓, 以上似乎還是一些細(xì)節(jié), 實際上多核這東西已經(jīng)有對應(yīng)的抽象理論, 稱為分布式計算 另外有個petri 網(wǎng)也是專門研究異步的, 就是把并行異步的邏輯模型單獨把出來搞.

zylthinking

這里是說的順序模型。不過這個是最重要的。

因為亂序模型是根據(jù)順序模型來設(shè)計的，mb()的作用，就 ...
塑料袋 發(fā)表于 2011-09-10 21:34

樓主能否解釋的更清楚一些， 或者推薦幾本資料； 一直對亂序執(zhí)行莫測高深， 怎么也不明白怎么能亂序而不影響執(zhí)行結(jié)果， 也不明白怎么在代碼級能夠預(yù)測亂序的發(fā)生

塑料袋

《super-scalar processor design》: 這本側(cè)重亂序，超標(biāo)量等。
《Memory Consistency Models for Shared-Memory Multiprocessors》：這本側(cè)重多核的抽象模型。


亂序的基本原理就是“取指”，“譯碼”都是順序的；  

大部分指令的執(zhí)行結(jié)果都要寫回到一個寄存器中，雖然指令的“執(zhí)行”是亂序的，但是還是順序的將結(jié)果“提交到”register file，即真正的寫到寄存器中。

CPU在“譯碼”階段，額外給每條指令關(guān)聯(lián)了一個唯一的ID號, 將來通過這個ID號，即可檢索到這條指令的執(zhí)行結(jié)果。

CPU在“譯碼”階段，如果一條指令依賴于上條指令，那么上條指令的ID號，即是本條指令的源操作數(shù)；或者上條條指令已經(jīng)執(zhí)行完畢，那么上條指令的執(zhí)行結(jié)果，即是本條指令的源操作數(shù)。

CPU一股腦的“譯碼”了一大片指令，每條指令“執(zhí)行”完畢后，都會將其ID號與執(zhí)行結(jié)果在CPU內(nèi)部廣播。 源操作數(shù)為這個ID號的已譯碼指令，會將源操作數(shù)從ID號置換為這個執(zhí)行結(jié)果。

這樣，源操作數(shù)里不包含ID號的指令就可以“執(zhí)行”，源操做數(shù)里還包含著ID號的指令就等待，由此來的“亂序”。




不過，CPU是亂序的，其讀寫內(nèi)存完全可能是順序的，這要視其load / store unit的設(shè)計。

open sparc的specification里比較詳細(xì)的描述了load / store unit的設(shè)計。

《Memory Consistency Models for Shared-Memory Multiprocessors》里，描述了load / store unit的一般性設(shè)計，并描述了分析其設(shè)計需求的方法。

tempname2

大濕高處不勝寒啊~~