簡體   English   中英

操作系統循環線程調度

[英]OS Round Robin thread scheduling

假設您有一個操作系統嘗試在循環調度中運行線程。 我知道有兩種情況操作系統會嘗試在多個線程之間切換:(可能還有更多......)

  1. 當當前線程實際上自己更早地讓出 CPU 時。
  2. 當操作系統接收到定時器中斷時。 問題是假設操作系統的最大計算綁定時間為 5 毫秒。 (操作系統每5ms接收一次定時器中斷)這個假設意味着每個線程最多可以擁有一個CPU內核5ms。

如果一個進程/線程在 5ms 之前完成它的時間片會發生什么? 這是否會導致下一個線程被調度為具有小於 5 毫秒的計算綁定時間,因為下一個定時器中斷將發生並且線程將別無選擇,只能放棄 CPU?

具體例子:
如果一個進程/線程在 5 毫秒之前完成它的時間片,比如說 2 毫秒,會發生什么? 我知道將安排另一個線程,但是該線程是否有 5 毫秒的全時切片,或者下一個線程在下一個定時器中斷發生之前只有 3 毫秒?

這個問題可能取決於操作系統(未提供)。 在主流操作系統上,產生任務通常會等待資源或給定時間。 除非它准備好(完成 IO 操作、可用鎖、超時等),否則操作系統不會重新調度它。 當新任務准備就緒時,操作系統調度程序可以自由地等待時間片結束或重新調度前一個任務。 重新調度任務以提高多線程應用程序的響應能力是很常見的(當代碼嘗試持有已被占用的鎖時等待幾毫秒是不合理的)。 話雖如此,這種行為通常不會如此直接地實現。 Windows 利用優先級提升來做到這一點。 在 Linux 上,CFS 嘗試使調度公平,以便所有任務在所有可用資源(例如內核)上都有平衡的時間。 目標任務的優先級也很重要。 一些著名游戲機的操作系統默認使用循環調度器,如果沒有高優先級任務,它們只會調度低優先級任務。 在這樣的系統上,當一個更高優先級的任務准備好時,當前的任務被直接中斷(除了上下文切換的開銷之外沒有延遲)。

簡而言之,操作系統不必等待定時器中斷來進行上下文切換。 此外,是的,時間片通常不會留空,因此它們會被其他任務重用。 計划任務是否可以在一個完整的時間片中進行調度取決於實際的 OS 調度程序。 另請注意,線程不會“放棄 CPU”:用戶級線程對此沒有真正的控制權。 在實踐中,在系統調用期間完成類似schedule的 kernel 調用(導致當前任務的上下文切換),或者系統中斷導致執行通常執行此schedule的 kernel 代碼 - 類似 Z50484C19F1AFDAF3842Z1A0D的一個時間片。

線程可以通過多種方式讓步,例如在信號量、輸入、output 等上發布或等待。如果線程讓步,或者它的調度計時器超時(5 毫秒),操作系統將翻閱線程列表以查看還有什么可以運行的。

這種翻找實際上涉及遍歷線程列表並查看它們的狀態。

  • 某些線程可能被列為“搶占”(即它們沒有讓步,OS 5ms 調度計時器超時並且操作系統已暫停它們以支持另一個線程)在這種情況下,其中一個可以簡單地恢復(寄存器恢復,程序計數器設置,CPU 從該點開始)。 輪詢調度只是一個額外的信息,即“這個線程最后一次運行是什么時候?”,操作系統偏愛沒有運行的線程比所有其他線程都長。
  • 其他將被列為等待 I/O(因此無法運行),還有更多將被列為等待信號量等鎖(因此也無法運行)。
  • 請注意,像 sem_post() 之類的東西也是一個產量,讓操作系統有機會進行這種翻找,也許會找到一個被列為等待剛剛發布的信號量的線程。

如果操作系統確定在所有進程中根本沒有可運行的線程(沒有任何東西在等待信號量,所有東西都掛起等待 I/O),並且它自己沒有任何事情要做,那么接下來發生的事情取決於 CPU。 對於一些較舊的 CPU,操作系統實際上必須進入一個無限循環,等待某個設備觸發一些中斷。 更現代的 CPU 有一條指令,該指令將暫停執行,直到某些中斷觸發。

基本上,操作系統調度程序是部分中斷服務例程(響應計時器或設備中斷),以及部分“普通”代碼,當線程自願讓步時,它只是管理線程列表。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM