[理工]108台大 計系4 8

作者: bluesea32541 (bluesea)   2020-01-17 00:24:25
https://i.imgur.com/8RyhyTU.jpg
https://i.imgur.com/vQC1cCO.jpg
想問這兩題怎麼排
https://i.imgur.com/MhDAV0c.jpg
可以大致提一下各小題的概念嗎Q
作者: DLHZ ( )   2020-01-17 00:34:00
data cache我認為是最簡單 不需要什麼特別的設計 應該說完全無關?然後single issue 再來是pipeline、superscalar、speculative 最後是out of order
作者: plsmaop (plsmaop)   2020-01-17 07:23:00
8.(a)這種交易都很短不會拖太長,在 optimistic lock 加上 priority scheduler 先讓金額高的 commit8(b),用一個 node 給順序,所有人第一步就是去跟那個 node 要一個嚴格遞增的序號,結帳時出示訊號,如果上一個完成結帳是要結帳的人的序號+1才可以結帳8(c)共識演算法或 two phase commit8(d) 大量寫入求 throughput 請參考 LSM 樹8(e) 大量 transaction 不斷 abort 導致 DDoS,用 CDN,rate limiter,或商品預先分區
作者: DLHZ ( )   2020-01-17 07:36:00
推大神
作者: mistel (Mistel)   2020-01-17 08:42:00
請問我看書上是寫說樂觀並行控制不適用於大量多筆可能彼此衝突的交易,所以這時候適合用這個方式嗎? 我自己是寫利用協調者決定誰可以進入臨界區間(才能扣庫存但我覺得這樣效能會變差 所以不知道...咦等等,我看錯題號了 那沒事了所以第一題是問即使可能交易出錯也沒差的囉?
作者: plsmaop (plsmaop)   2020-01-17 08:55:00
樂觀鎖不會出錯啦,是 commit 時決定可不可以 commit,確實你說大量衝突有可能導致效能不好,那改用悲觀鎖也可,我覺得重點在於 priority scheduler 選賺最多錢的 transactionpostgres 就樂觀鎖加上 multiversion concurrency control
作者: mistel (Mistel)   2020-01-17 09:01:00
瞭解,那能不能再問一下c小題拿樂觀鎖或類似的機制來作答可以嗎?不是很懂two-phase commit跟樂觀鎖或two-phase locking之間的功能有什麼差異
作者: plsmaop (plsmaop)   2020-01-17 09:15:00
two phase commit 是分散式系統之間維持一致性,two phase lock 是同一台電腦上不同 transaction 在存取相同的東西時確保交易正確且不會出現死鎖樂觀鎖跟多版本並行是一起的,transaction 開始時該 transaction 會記住開始時資料的模樣,給一個版號然後直接修改,commit 時檢查自己的版號是不是最新的,不是就得 abort悲觀鎖則是要存取資料前一定要取得鎖才行,然後加上 2PL來確保同時處理的 transaction 們的執行結果跟一個一個處理時是一樣的(serializable)如果還要考慮 transaction abort 所造成 phantom read,就要採用 strict 2PL
作者: mistel (Mistel)   2020-01-17 09:24:00
我懂了!!謝謝p大 講的好清楚
作者: plsmaop (plsmaop)   2020-01-17 09:24:00
上面有錯喔,2PL 還是有死鎖,2PL 的重點在於確保 serializability,就是多個 transaction 同時進行,但結果必須跟一個一個處理多個 transaction 一樣
作者: ccapricorntw (Eating)   2020-01-17 16:20:00
4c 我是排container>VM>GPGPU>Hyper-thread>superscaler>pipeline 不過不是很確定另外想問一下一樓D大為何speculative會比superscaler難處理exception?
作者: DLHZ ( )   2020-01-17 16:56:00
我好像想錯了 speculative的部分應該跟exception的處理沒什麼關係 而且看起來不代表他有pipeline?我重新排一次好了 cache無關最簡單 然後我再想了一次認為single issue, speculative, superscalar一樣 讓control signal去改pc就好 再來pipeline 最後out of order+superscalar抱歉跟前面差有點多 想的太隨便==superscalar還是複雜一點(unit較多)然後speculative中像BTB之類的可能還是要處理 但是相對較少 所以那三個再分下來應該是 single issue, speculative, superscalar崩潰 大家看看就好 我越想越不對勁
作者: ccapricorntw (Eating)   2020-01-17 17:47:00
XD 但我認為pipeline比較簡單耶 pipeline如果在EXE發生exception 頂多flush IF跟ID的指令但是superscalar可能要flush所有unit的指令
作者: DLHZ ( )   2020-01-17 21:07:00
我想說以pipeline的設計還要決定flush哪裡 如果比較簡易的只要讓他全部flush就好
作者: ccapricorntw (Eating)   2020-01-17 22:15:00
superscalar也不一定全flush吧?應該只會flush在原本order發生exception的指令後的指令吧?
作者: DLHZ ( )   2020-01-17 22:23:00
因為他只有說superscalar 我想說不一定是pipeline吧?
作者: ccapricorntw (Eating)   2020-01-17 22:34:00
也是 不過有沒有pipeline的運作上有甚麼差R?這塊不太熟QQ
作者: DLHZ ( )   2020-01-17 22:38:00
有pipeline應該就是單純分階段?不過所有superscalar的例子都是implement在pipeline上 這也是我的猜測而已
作者: dsa66253 (Kobe Mary)   2020-01-18 23:52:00
請問p大 這些內容是在分散式系統裡嗎?應該是要修什麼課程比較能夠有通盤理解?

Links booklink

Contact Us: admin [ a t ] ucptt.com