[理工]108台大 計系4 8

[bluesea32541 (bluesea)]

https://i.imgur.com/8RyhyTU.jpg
https://i.imgur.com/vQC1cCO.jpg
想問這兩題怎麼排

https://i.imgur.com/MhDAV0c.jpg
可以大致提一下各小題的概念嗎Q

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 123.192.209.180 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Grad-ProbAsk/M.1579191867.A.A40.html
→ DLHZ: data cache我認為是最簡單 不需要什麼特別的設計 應該說完全
→ DLHZ: 無關？然後single issue 再來是pipeline、superscalar、spec
→ DLHZ: ulative 最後是out of order
了解～感謝！
推 plsmaop: 8.（a)這種交易都很短不會拖太長，在 optimistic lock 加
→ plsmaop: 上 priority scheduler 先讓金額高的 commit
推 plsmaop: 8(b)，用一個 node 給順序，所有人第一步就是去跟那個 no
→ plsmaop: de 要一個嚴格遞增的序號，結帳時出示訊號，如果上一個
→ plsmaop: 完成結帳是要結帳的人的序號+1才可以結帳
推 plsmaop: 8(c)共識演算法或 two phase commit
推 plsmaop: 8(d) 大量寫入求 throughput 請參考 LSM 樹
推 plsmaop: 8(e) 大量 transaction 不斷 abort 導致 DDoS，用 CDN，r
→ plsmaop: ate limiter，或商品預先分區
推 DLHZ: 推大神
推 mistel: 請問我看書上是寫說樂觀並行控制不適用於大量多筆可能彼
→ mistel: 此衝突的交易，所以這時候適合用這個方式嗎？ 我自己是寫
→ mistel: 利用協調者決定誰可以進入臨界區間(才能扣庫存
→ mistel: 但我覺得這樣效能會變差 所以不知道...
推 mistel: 咦等等，我看錯題號了 那沒事了
→ mistel: 所以第一題是問即使可能交易出錯也沒差的囉？
推 plsmaop: 樂觀鎖不會出錯啦，是 commit 時決定可不可以 commit，確
→ plsmaop: 實你說大量衝突有可能導致效能不好，那改用悲觀鎖也可，
→ plsmaop: 我覺得重點在於 priority scheduler 選賺最多錢的 transa
→ plsmaop: ction
→ plsmaop: postgres 就樂觀鎖加上 multiversion concurrency contro
→ plsmaop: l
推 mistel: 瞭解，那能不能再問一下c小題拿樂觀鎖或類似的機制來作答
→ mistel: 可以嗎？不是很懂two-phase commit跟樂觀鎖或two-phase l
→ mistel: ocking之間的功能有什麼差異
推 plsmaop: two phase commit 是分散式系統之間維持一致性，two phas
→ plsmaop: e lock 是同一台電腦上不同 transaction 在存取相同的東
→ plsmaop: 西時確保交易正確且不會出現死鎖
推 plsmaop: 樂觀鎖跟多版本並行是一起的，transaction 開始時該 tran
→ plsmaop: saction 會記住開始時資料的模樣，給一個版號然後直接修
→ plsmaop: 改，commit 時檢查自己的版號是不是最新的，不是就得 abo
→ plsmaop: rt
推 plsmaop: 悲觀鎖則是要存取資料前一定要取得鎖才行，然後加上 2PL
→ plsmaop:  來確保同時處理的 transaction 們的執行結果跟一個一個
→ plsmaop: 處理時是一樣的（serializable）
→ plsmaop: 如果還要考慮 transaction abort 所造成 phantom read，
→ plsmaop: 就要採用 strict 2PL
推 mistel: 我懂了！！謝謝p大 講的好清楚
推 plsmaop: 上面有錯喔，2PL 還是有死鎖，2PL 的重點在於確保 serial
→ plsmaop: izability，就是多個 transaction 同時進行，但結果必須
→ plsmaop: 跟一個一個處理多個 transaction 一樣
感謝p大！！真的很詳細
※ 編輯: bluesea32541 (123.192.209.180 臺灣), 01/17/2020 10:29:37
推 ccapricorntw: 4c 我是排container>VM>GPGPU>Hyper-thread>supersc
→ ccapricorntw: aler>pipeline 不過不是很確定
推 ccapricorntw: 另外想問一下一樓D大為何speculative會比superscale
→ ccapricorntw: r難處理exception？
→ DLHZ: 我好像想錯了 speculative的部分應該跟exception的處理沒什
→ DLHZ: 麼關係 而且看起來不代表他有pipeline?
→ DLHZ: 我重新排一次好了 cache無關最簡單 然後我再想了一次認為sin
→ DLHZ: gle issue, speculative, superscalar一樣 讓control signal
→ DLHZ: 去改pc就好 再來pipeline 最後out of order+superscalar
→ DLHZ: 抱歉跟前面差有點多 想的太隨便==
→ DLHZ: superscalar還是複雜一點(unit較多)然後speculative中像BTB
→ DLHZ: 之類的可能還是要處理 但是相對較少 所以那三個再分下來應該
→ DLHZ: 是 single issue, speculative, superscalar
→ DLHZ: 崩潰 大家看看就好 我越想越不對勁
推 ccapricorntw: XD 但我認為pipeline比較簡單耶 pipeline如果在EXE
→ ccapricorntw: 發生exception 頂多flush IF跟ID的指令
→ ccapricorntw: 但是superscalar可能要flush所有unit的指令
→ DLHZ: 我想說以pipeline的設計還要決定flush哪裡 如果比較簡易的只
→ DLHZ: 要讓他全部flush就好
→ ccapricorntw: superscalar也不一定全flush吧？應該只會flush在
→ ccapricorntw: 原本order發生exception的指令後的指令吧？
→ DLHZ: 因為他只有說superscalar 我想說不一定是pipeline吧？
→ ccapricorntw: 也是 不過有沒有pipeline的運作上有甚麼差R？
→ ccapricorntw: 這塊不太熟QQ
→ DLHZ: 有pipeline應該就是單純分階段?不過所有superscalar的例子
→ DLHZ: 都是implement在pipeline上 這也是我的猜測而已
推 dsa66253: 請問p大 這些內容是在分散式系統裡嗎？應該是要修什麼
→ dsa66253: 課程比較能夠有通盤理解？