彩票調度算法——讓進程們拼手氣？

這篇文章主要想介紹下彩票調度（我的以爲這個算法很是有意思~ ），還有隨機算法相對傳統算法的一點優點，畢竟如今絕大多數算法都是追求肯定性，尤爲在操做系統，你們都但願一切可控，因此隨機算法的出現聽起來有些「不合時宜」，但它確實可以解決某些傳統算法難以解決的邊角問題（算是給本身挖個坑，之後可能會寫），也爲咱們提供了一種新的思路。

如下是正文：

---

進程調度器今天忽然召集大夥，說是要討論一件重要的事情，問他他還賣關子：「你去了就知道，我如今不告訴大家。」

還沒到約定時間，大夥兒就已經來到了內存家，只見進程調度器氣定神閒的坐在椅子上，翹着個二郎腿，好不自在。

「調度器老哥，如今人也都來的差很少了，我們如今就開始吧，早點結束你們夥兒好接着回去幹活啊。」

調度器「嗯」了一聲，起身走向白板，說：「我向你們先說明一下背景吧，我們原來的調度算法，好比先來先服務，短進程優先，優先級調度等等，大都是爲了優化週轉時間和響應時間，效果也還不錯。不過這些算法，有些可能會致使飢餓的問題，我想很多進程深有體會。」

飢餓問題確實困擾操做系統很長時間了，雖然飢餓不如死鎖那麼有破壞力，但仍是影響到了進程家庭內部的和諧。聽調度器的意思，他是能解決這個問題？

幾個低優先級進程開始小聲議論起來，像他們這種優先級別低的，總會由於高優先級進程「插隊」而得不到 CPU 資源，內心早就憋着一口氣呢。忍不住問調度器：「如今是有什麼好辦法了嗎？咱們可受夠飢餓的生活了！」

調度器得意的說：「那固然，否則我今天把大家大夥叫過來幹什麼？我最近想到一個好點子，我們能夠調整一下調度目標，改爲確保每一個任務得到必定比例的 CPU 時間，這樣只要咱們提早約定好份額，每一個人最後均可以享受到應有的待遇，不可能出現某一進程獨佔的現象！聽起來是否是很公平？我打算把這類算法叫「比例份額調度」或者「公平份額調度」。」

系統進程提出了質疑：「公平？你別說大話了，這個目標我們又不是沒有追求過，也就時間片輪轉算法勉強達到了咱們的要求，可一旦再劃分出優先級（指的是多級優先隊列調度），就可能會形成進程飢餓，追求公平可不是那麼簡單的！」

「你先聽我說嘛，絕對的公平確實很難達到，咱們如今退而求其次，追求一個相對公平——就是說短期裏可能會有些許不公平，但從長期來看，你們在 CPU 上運行的時間所佔比例就是一開始約定好的。」

「聽起來頗有道理，可是你打算怎麼實現？」

「嘿嘿，我給這個方法取名叫「彩票調度」，我們一開始的時候給每一個進程發彩票——優先級越高，發的彩票越多，而後每隔一段時間（一個時間片），舉行一次彩票抽獎，抽出來的號是誰的，誰就能運行~」

「哈哈哈哈，我還覺得是什麼厲害的算法呢」，一時間，你們都笑了出來，整個內存裏充滿了快活的氣息。調度器的臉唰的一下就紅了。

操做系統吐槽道：「調度器，你是否是跟那幫人類學壞了？在咱們這兒還搞什麼彩票，下一步是否是打算騙你們的時間片？再這麼搞下去，當心我把你職位撤了啊！」

調度器趕忙爲本身解釋：」誒，我但是通過深思熟慮纔想出來的，大家別誤會啊！打個比方吧，假若有兩個進程 A 和 B，我想讓 A 佔用 80% 的 CPU 時間，B 佔用 20% 的 CPU 時間，我就給 A 發80 張彩票，給 B 發 20 張彩票。**這樣，每次抽獎的時候，A 就有 80% 的機率佔用 CPU，從數學指望上講，1 秒鐘以內，A 能運行 800ms。**我是打算利用隨機性來達到按比例分配的目標的，可從沒打算騙你們。「

操做系統看起來有點承認這個算法了，他點點頭：「有點意思，你接着說下去。」

調度器鬆了一口氣，繼續說：「我以爲這種算法有個很好的地方——即便某進程只有一張彩票，通過多輪迭代，他總會得到 CPU 的使用權。因此飢餓的問題就能解決了~」

PS：可別跟現實的彩票等價啊，現實彩票中獎率低的嚇人。。。無法比的（不信你本身算一算）。

那幾個常常飢餓的進程聽了，兩眼放光，彷彿抓到了但願。

"別急，還沒完呢！大家想一想，我們用過的**「最短響應比優先」算法，還得記錄每一個進程在就緒隊列等待了多長時間**，多麻煩！我這個「彩票調度」，不須要記錄任何狀態，拿來就用，特別的輕量，並且這種隨機方法很快，只要生成一個隨機數，就能快速作出決策。爲了向大家展現，我還特地寫了段僞代碼。"

//當進入時鐘中斷時運行

//counter 用來數哪一個進程拿到了 winner 彩票
int counter = 0;

//選出勝者，其中 totalticks 是彩票總數
int winner = randint(0, totaltickets);

//指針，指向隊列裏的進程
job_t *current_job = head;
    
while(current_job != null)
{
	counter = counter + current_job->ticket;
	
	if (counter > winner)//說明當前進程拿到了 winner 彩票
		break;
	
	current_job = current_job->next;
}

//切換至 current 指向的進程

操做系統看完了代碼，讚歎道：「好傢伙，確實是個簡潔的調度算法，簡潔的都有點兒難以想象了。不過你這個代碼只解決了調度問題，最開始的彩票分配問題你打算怎麼解決？」

調度器面露難色：「我這幾天也在想這個問題，不過暫時沒有想到好的解決方案，因此說要靠試運行來摸索嘛，若是找到好的分配方法，就能夠長期運行下去了。」

「確實，我也以爲這個方法有的一試，我們明天就按這個調度算法來，看看效果能不能比上現有的算法！」

調度器高興地叫出來：「好，太好了，我立刻就去準備！」

---

實際上彩票調度並無在 CPU 調度程序裏普遍使用，一個緣由是不能很好的適合 I/O（有論文研究過這個問題），另外一個緣由就是文中所提到的，票數分配問題沒有肯定的解決方式，好比你新打開了一個瀏覽器進程，那該給他分配多少票？票數少了，響應跟不上，票數多了，又會浪費 CPU 時間。

與此相比，常見的通用調度程序，好比多級優先隊列，就作的很好，所以如今獲得了普遍的應用。

但不表明這種思想就沒有用了，在某些容易肯定份額比例的領域裏，比例份額調度程序就更有用——好比在虛擬數據中心，你可能但願 1/4 的 CPU 時間給 Windows 虛擬機，剩下的時間給 Linux 虛擬機，這時候靠彩票調度就很方便了。

因此彩票調度機制仍是有必定應用價值的，說不定你之後在哪裏就用上了呢？

但願你在看完個人文章以後有所收穫，期待你的贊和轉發！

若是本文對你有幫助，歡迎關注個人公衆號 tobe的囈語 ，帶你深刻計算機的世界～ 公衆號後臺回覆關鍵詞【計算機】有驚喜哦~