[理工]108台大 計系4 8

看板Grad-ProbAsk作者 (bluesea)時間4年前 (2020/01/17 00:24), 4年前編輯推噓19(19推 0噓 53→)
留言72則, 5人參與, 4年前最新討論串1/1
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
→
01/17 00:34, 4年前 , 1F
data cache我認為是最簡單 不需要什麼特別的設計 應該說完全
01/17 00:34, 1F
→
01/17 00:34, 4年前 , 2F
無關？然後single issue 再來是pipeline、superscalar、spec
01/17 00:34, 2F
→
01/17 00:34, 4年前 , 3F
ulative 最後是out of order
01/17 00:34, 3F
了解～感謝！
推
01/17 07:23, 4年前 , 4F
8.（a)這種交易都很短不會拖太長，在 optimistic lock 加
01/17 07:23, 4F
→
01/17 07:23, 4年前 , 5F
上 priority scheduler 先讓金額高的 commit
01/17 07:23, 5F
推
01/17 07:25, 4年前 , 6F
8(b)，用一個 node 給順序，所有人第一步就是去跟那個 no
01/17 07:25, 6F
→
01/17 07:25, 4年前 , 7F
de 要一個嚴格遞增的序號，結帳時出示訊號，如果上一個
01/17 07:25, 7F
→
01/17 07:25, 4年前 , 8F
完成結帳是要結帳的人的序號+1才可以結帳
01/17 07:25, 8F
推
01/17 07:28, 4年前 , 9F
8(c)共識演算法或 two phase commit
01/17 07:28, 9F
推
01/17 07:29, 4年前 , 10F
8(d) 大量寫入求 throughput 請參考 LSM 樹
01/17 07:29, 10F
推
01/17 07:31, 4年前 , 11F
8(e) 大量 transaction 不斷 abort 導致 DDoS，用 CDN，r
01/17 07:31, 11F
→
01/17 07:31, 4年前 , 12F
ate limiter，或商品預先分區
01/17 07:31, 12F
推
01/17 07:36, 4年前 , 13F
推大神
01/17 07:36, 13F
推
01/17 08:42, 4年前 , 14F
請問我看書上是寫說樂觀並行控制不適用於大量多筆可能彼
01/17 08:42, 14F
→
01/17 08:42, 4年前 , 15F
此衝突的交易，所以這時候適合用這個方式嗎？ 我自己是寫
01/17 08:42, 15F
→
01/17 08:42, 4年前 , 16F
利用協調者決定誰可以進入臨界區間(才能扣庫存
01/17 08:42, 16F
→
01/17 08:44, 4年前 , 17F
但我覺得這樣效能會變差 所以不知道...
01/17 08:44, 17F
推
01/17 08:47, 4年前 , 18F
咦等等，我看錯題號了 那沒事了
01/17 08:47, 18F
→
01/17 08:47, 4年前 , 19F
所以第一題是問即使可能交易出錯也沒差的囉？
01/17 08:47, 19F
推
01/17 08:55, 4年前 , 20F
樂觀鎖不會出錯啦，是 commit 時決定可不可以 commit，確
01/17 08:55, 20F
→
01/17 08:55, 4年前 , 21F
實你說大量衝突有可能導致效能不好，那改用悲觀鎖也可，
01/17 08:55, 21F
→
01/17 08:55, 4年前 , 22F
我覺得重點在於 priority scheduler 選賺最多錢的 transa
01/17 08:55, 22F
→
01/17 08:55, 4年前 , 23F
ction
01/17 08:55, 23F
→
01/17 08:55, 4年前 , 24F
postgres 就樂觀鎖加上 multiversion concurrency contro
01/17 08:55, 24F
→
01/17 08:55, 4年前 , 25F
l
01/17 08:55, 25F
推
01/17 09:01, 4年前 , 26F
瞭解，那能不能再問一下c小題拿樂觀鎖或類似的機制來作答
01/17 09:01, 26F
→
01/17 09:01, 4年前 , 27F
可以嗎？不是很懂two-phase commit跟樂觀鎖或two-phase l
01/17 09:01, 27F
→
01/17 09:01, 4年前 , 28F
ocking之間的功能有什麼差異
01/17 09:01, 28F
推
01/17 09:15, 4年前 , 29F
two phase commit 是分散式系統之間維持一致性，two phas
01/17 09:15, 29F
→
01/17 09:15, 4年前 , 30F
e lock 是同一台電腦上不同 transaction 在存取相同的東
01/17 09:15, 30F
→
01/17 09:15, 4年前 , 31F
西時確保交易正確且不會出現死鎖
01/17 09:15, 31F
推
01/17 09:18, 4年前 , 32F
樂觀鎖跟多版本並行是一起的，transaction 開始時該 tran
01/17 09:18, 32F
→
01/17 09:18, 4年前 , 33F
saction 會記住開始時資料的模樣，給一個版號然後直接修
01/17 09:18, 33F
→
01/17 09:18, 4年前 , 34F
改，commit 時檢查自己的版號是不是最新的，不是就得 abo
01/17 09:18, 34F
→
01/17 09:18, 4年前 , 35F
rt
01/17 09:18, 35F
推
01/17 09:21, 4年前 , 36F
悲觀鎖則是要存取資料前一定要取得鎖才行，然後加上 2PL
01/17 09:21, 36F
→
01/17 09:21, 4年前 , 37F
來確保同時處理的 transaction 們的執行結果跟一個一個
01/17 09:21, 37F
→
01/17 09:21, 4年前 , 38F
處理時是一樣的（serializable）
01/17 09:21, 38F
→
01/17 09:22, 4年前 , 39F
如果還要考慮 transaction abort 所造成 phantom read，
01/17 09:22, 39F
→
01/17 09:22, 4年前 , 40F
就要採用 strict 2PL
01/17 09:22, 40F
推
01/17 09:24, 4年前 , 41F
我懂了！！謝謝p大 講的好清楚
01/17 09:24, 41F
推
01/17 09:24, 4年前 , 42F
上面有錯喔，2PL 還是有死鎖，2PL 的重點在於確保 serial
01/17 09:24, 42F
→
01/17 09:24, 4年前 , 43F
izability，就是多個 transaction 同時進行，但結果必須
01/17 09:24, 43F
→
01/17 09:24, 4年前 , 44F
跟一個一個處理多個 transaction 一樣
01/17 09:24, 44F
感謝p大！！真的很詳細 ※ 編輯: bluesea32541 (123.192.209.180 臺灣), 01/17/2020 10:29:37
推
01/17 16:20, 4年前 , 45F
4c 我是排container>VM>GPGPU>Hyper-thread>supersc
01/17 16:20, 45F
→
01/17 16:20, 4年前 , 46F
aler>pipeline 不過不是很確定
01/17 16:20, 46F
推
01/17 16:23, 4年前 , 47F
另外想問一下一樓D大為何speculative會比superscale
01/17 16:23, 47F
→
01/17 16:23, 4年前 , 48F
r難處理exception？
01/17 16:23, 48F
→
01/17 16:56, 4年前 , 49F
我好像想錯了 speculative的部分應該跟exception的處理沒什
01/17 16:56, 49F
→
01/17 16:56, 4年前 , 50F
麼關係 而且看起來不代表他有pipeline?
01/17 16:56, 50F
→
01/17 16:57, 4年前 , 51F
我重新排一次好了 cache無關最簡單 然後我再想了一次認為sin
01/17 16:57, 51F
→
01/17 16:57, 4年前 , 52F
gle issue, speculative, superscalar一樣 讓control signal
01/17 16:57, 52F
→
01/17 16:57, 4年前 , 53F
去改pc就好 再來pipeline 最後out of order+superscalar
01/17 16:57, 53F
→
01/17 17:00, 4年前 , 54F
抱歉跟前面差有點多 想的太隨便==
01/17 17:00, 54F
→
01/17 17:06, 4年前 , 55F
superscalar還是複雜一點(unit較多)然後speculative中像BTB
01/17 17:06, 55F
→
01/17 17:06, 4年前 , 56F
之類的可能還是要處理 但是相對較少 所以那三個再分下來應該
01/17 17:06, 56F
→
01/17 17:06, 4年前 , 57F
是 single issue, speculative, superscalar
01/17 17:06, 57F
→
01/17 17:17, 4年前 , 58F
崩潰 大家看看就好 我越想越不對勁
01/17 17:17, 58F
推
01/17 17:47, 4年前 , 59F
XD 但我認為pipeline比較簡單耶 pipeline如果在EXE
01/17 17:47, 59F
→
01/17 17:48, 4年前 , 60F
發生exception 頂多flush IF跟ID的指令
01/17 17:48, 60F
→
01/17 17:48, 4年前 , 61F
但是superscalar可能要flush所有unit的指令
01/17 17:48, 61F
→
01/17 21:07, 4年前 , 62F
我想說以pipeline的設計還要決定flush哪裡 如果比較簡易的只
01/17 21:07, 62F
→
01/17 21:07, 4年前 , 63F
要讓他全部flush就好
01/17 21:07, 63F
→
01/17 22:15, 4年前 , 64F
superscalar也不一定全flush吧？應該只會flush在
01/17 22:15, 64F
→
01/17 22:15, 4年前 , 65F
原本order發生exception的指令後的指令吧？
01/17 22:15, 65F
→
01/17 22:23, 4年前 , 66F
因為他只有說superscalar 我想說不一定是pipeline吧？
01/17 22:23, 66F
→
01/17 22:34, 4年前 , 67F
也是 不過有沒有pipeline的運作上有甚麼差R？
01/17 22:34, 67F
→
01/17 22:35, 4年前 , 68F
這塊不太熟QQ
01/17 22:35, 68F
→
01/17 22:38, 4年前 , 69F
有pipeline應該就是單純分階段?不過所有superscalar的例子
01/17 22:38, 69F
→
01/17 22:38, 4年前 , 70F
都是implement在pipeline上 這也是我的猜測而已
01/17 22:38, 70F
推
01/18 23:52, 4年前 , 71F
請問p大 這些內容是在分散式系統裡嗎？應該是要修什麼
01/18 23:52, 71F
→
01/18 23:52, 4年前 , 72F
課程比較能夠有通盤理解？
01/18 23:52, 72F
‣ 更多 bluesea32541 的文章
文章代碼(AID): #1U88uxf0 (Grad-ProbAsk)