104清大計系第二題

看板Grad-ProbAsk作者 (馬吉叫我辦的)時間9年前 (2016/11/15 22:29), 編輯推噓7(7推 0噓 57→)
留言64則, 6人參與, 最新討論串1/1
想請教一下第二題在問什麼? 看不懂題目的意思 http://i.imgur.com/3SZy80N.jpg
-- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 182.235.130.102 ※ 文章網址: https://www.ptt.cc/bbs/Grad-ProbAsk/M.1479220161.A.7BD.html
→
11/16 00:01, , 1F
這題應該是OS 恐龍本的習題
11/16 00:01, 1F
→
11/16 00:03, , 2F
A. 可以使該 Process 跑複數次
11/16 00:03, 2F
→
11/16 00:05, , 3F
B. 優勢: 不用變換Scheduler Algorithem 就可以保證
11/16 00:05, 3F
推
11/16 00:05, , 4F
可以讓它pritority較高的意味 獲得的時間會相對比較多
11/16 00:05, 4F
→
11/16 00:06, , 5F
藉由複數的pointer 來完成以下兩項事情
11/16 00:06, 5F
→
11/16 00:07, , 6F
1. 重要的Process可以藉由多次的running來完成
11/16 00:07, 6F
→
11/16 00:07, , 7F
2.避免Low-priority 的process被餓死
11/16 00:07, 7F
→
11/16 00:08, , 8F
劣勢: Context Switch 變更多
11/16 00:08, 8F
→
11/16 00:10, , 9F
C. 允許 quantum time 依情況不同而改變
11/16 00:10, 9F
→
11/16 00:13, , 10F
關於題目 它是指 Ready Queue 中 你可以把它想像成
11/16 00:13, 10F
→
11/16 00:14, , 11F
「Link list」別想像成 Array , 我在每個Process
11/16 00:14, 11F
→
11/16 00:15, , 12F
某個Process 旁邊接了複數個 Link 指向自己
11/16 00:15, 12F
→
11/16 00:16, , 13F
Dispatcher依照順序，Process 會持續重複的被select
11/16 00:16, 13F
→
11/16 00:16, , 14F
這個功用目的 優劣是為何
11/16 00:16, 14F
→
11/16 00:24, , 15F
context switch會增加 是因為每次 time quantum到了
11/16 00:24, 15F
→
11/16 00:24, , 16F
之後 time interrupt被觸發 dispatcher會先將原proce
11/16 00:24, 16F
→
11/16 00:24, , 17F
ss的 資料傳回 在載入下一個PCB 不管前後process是否
11/16 00:24, 17F
→
11/16 00:24, , 18F
是一樣的
11/16 00:24, 18F
推
11/16 10:47, , 19F
他怎麼避免low-priority process 餓死，是指原本R
11/16 10:47, 19F
→
11/16 10:47, , 20F
R本身的功能嗎？
11/16 10:47, 20F
→
11/16 10:52, , 21F
我的理解是 因為 RR 是平均給予process time quantum
11/16 10:52, 21F
→
11/16 10:53, , 22F
時間到就會換～大家一定都輪得到
11/16 10:53, 22F
→
11/16 10:54, , 23F
若要避免Low-priority process starvation 只要在該
11/16 10:54, 23F
→
11/16 10:55, , 24F
輪中給它加入pointer 就可避免
11/16 10:55, 24F
→
11/16 11:16, , 25F
我的誘惑是避免飢餓不是本身rr就有的特性嗎？這樣
11/16 11:16, 25F
→
11/16 11:16, , 26F
算是這個做法的"優點"嗎？
11/16 11:16, 26F
→
11/16 11:37, , 27F
這個做法會讓原本平衡的time sharing不公平不是有
11/16 11:37, 27F
→
11/16 11:37, , 28F
機會造成飢餓，反而是劣勢@@？
11/16 11:37, 28F
→
11/16 11:46, , 29F
RR算是FCFS 藉著time quantum 來preemptive 依然有
11/16 11:46, 29F
→
11/16 11:46, , 30F
可能starvation
11/16 11:46, 30F
→
11/16 11:49, , 31F
雖然照你說好像真的哪裡怪怪的 QQ
11/16 11:49, 31F
→
11/16 11:57, , 32F
剛剛看洪逸筆記真的如wind大所說的
11/16 11:57, 32F
→
11/16 12:02, , 33F
沒關係我們一起QQ，OS簡直天坑
11/16 12:02, 33F
→
11/16 12:12, , 34F
我是這麼猜想的 洪逸說的公平和避免飢餓是在Process
11/16 12:12, 34F
→
11/16 12:13, , 35F
完成時間並無限制的情況下，可以達到該效果
11/16 12:13, 35F
→
11/16 12:13, , 36F
而實際上各 Process 皆會有一個限制時間
11/16 12:13, 36F
→
11/16 12:14, , 37F
很難真得藉由RR達到實際情況的公平
11/16 12:14, 37F
→
11/16 12:16, , 38F
順便提供一下剛剛找的解答http://imgur.com/a/k2Q3h
11/16 12:16, 38F
推
11/16 12:33, , 39F
意思是說，我看誰比較餓，就讓他多跑幾次以達到公
11/16 12:33, 39F
→
11/16 12:33, , 40F
平這樣嗎？
11/16 12:33, 40F
→
11/16 12:50, , 41F
RR再加上multiple pointer 本身就是額外加priority
11/16 12:50, 41F
→
11/16 12:50, , 42F
給某process 就已經論不上公平了 這是優點 也感覺如
11/16 12:50, 42F
→
11/16 12:50, , 43F
你所說的是缺點
11/16 12:50, 43F
→
11/16 13:08, , 44F
這個缺點是違法RR Algorithms 的精神 但對於整個OS
11/16 13:08, 44F
→
11/16 13:08, , 45F
可以不用換scheduler algo就可以達到 若不需要這樣
11/16 13:08, 45F
→
11/16 13:08, , 46F
當然在該輪就不用加pointer就好
11/16 13:08, 46F
→
11/16 13:12, , 47F
話說我感覺我自己在繞圈圈了QQ
11/16 13:12, 47F
推
11/16 13:15, , 48F
所以解答的好處第二個拿去下面壞處第二個剛好是兩
11/16 13:15, 48F
→
11/16 13:15, , 49F
個這樣嗎XD，因為壞處第二個看不太懂
11/16 13:15, 49F
→
11/16 13:30, , 50F
討論過後我覺得壞處可以寫@@~
11/16 13:30, 50F
→
11/16 13:31, , 51F
壞處第二項我覺得是在講整個LINK變複雜了吧(?
11/16 13:31, 51F
推
11/16 13:41, , 52F
我的想法是他的做法是一個process可能有兩個pointer幫
11/16 13:41, 52F
→
11/16 13:41, , 53F
他在queue排隊,壞處第二項就是因為一個process執行結
11/16 13:41, 53F
→
11/16 13:42, , 54F
束,也要結束掉queue裡面的另外一個pointer,所以要搜尋
11/16 13:42, 54F
→
11/16 13:42, , 55F
整個串列
11/16 13:42, 55F
→
11/16 13:51, , 56F
11/16 13:51, 56F
→
11/16 13:51, , 57F
這篇解答說會餓死是缺點
11/16 13:51, 57F
推
11/16 14:06, , 58F
我懂了，我把他看成pointer是連續放進去的才想說
11/16 14:06, 58F
→
11/16 14:06, , 59F
，做完只要把後面一樣的砍掉就好，那照這個邏輯來
11/16 14:06, 59F
→
11/16 14:06, , 60F
看是不會有飢餓產生，只是時間分配不均而已，只是
11/16 14:06, 60F
→
11/16 14:06, , 61F
有的process在一輪裡面跑的時間比較長而已
11/16 14:06, 61F
推
11/16 14:10, , 62F
嗯嗯那我更正,只是低priority會分配較少但不會餓死
11/16 14:10, 62F
→
11/16 14:47, , 63F
yeah~終於有結論了，感謝各位大大
11/16 14:47, 63F
→
11/20 10:47, , 64F
非常感謝各位的回答
11/20 10:47, 64F
‣ 更多 h9638512 的文章
文章代碼(AID): #1OAnl1Uz (Grad-ProbAsk)