[理工]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