|
系統建立線程時,默認的線程是SCHED_OTHER。因此若是咱們要改變線程的調度策略的話,能夠經過下面的這個函數實現。
|
|
|
|
這裏測試一下其中的兩種特性,SCHED_OTHER和SCHED_RR,還有就是優先級的問題,是否是可以保證,高優先級的線程,就能夠保證先運行。
下面的這個測試程序,建立了三個線程,默認建立的線程的調度策略是SCHED_OTHER,其他的兩個線程的調度策略設置成SCHED_RR。個人Linux的內核版本是2.6.31。SCHED_RR是根據時間片來肯定線程的調度。時間片用完了,無論這個線程的優先級有多高都不會在運行,而是進入就緒隊列中,等待下一個時間片的到了,那這個時間片到底要持續多長時間?在《深刻理解Linux內核》中的第七章進程調度中,是這樣描訴的,Linux採起單憑經驗的方法,即選擇儘量長、同時能保持良好相應時間的一個時間片。這裏也沒有給出一個具體的時間來,可能會根據不一樣的CPU 來定,還有就是多CPU 的狀況。ui
|
下面是該程序的其中之一的運行結果:.net
|
這裏咱們能夠看到,因爲線程3的調度策略是SCHED_OTHER,而線程2的調度策略是SCHED_RR,因此,在Thread3中,線程3被線程1,線程2給搶佔了。因爲線程1的優先級大於線程2的優先級,因此,在線程1以先於線程2運行,不過,這裏線程2有一部分代碼仍是先於線程1運行了。
我原覺得,只要線程的優先級高,就會必定先運行,其實,這樣的理解是片面的,特別是在SMP的PC機上更會增長其不肯定性。
其實,普通進程的調度,是CPU根據進程優先級算出時間片,這樣並不能必定保證高優先級的進程必定先運行,只不過和優先級低的進程相比,一般優先級較高的進程得到的CPU時間片會更長而已。其實,若是要想保證一個線程運行完在運行另外一個線程的話,就要使用多線程的同步技術,信號量,條件變量等方法。而不是絕對依靠優先級的高低,來保證。
不過,從運行的結果上,咱們能夠看到,調度策略爲SCHED_RR的線程1,線程2確實搶佔了調度策略爲SCHED_OTHER的線程3。這個是能夠理解的,因爲SCHER_RR是實時調度策略。
只有在下述事件之一發生時,實時進程纔會被另一個進程取代。
(1) 進程被另一個具備更高實時優先級的實時進程搶佔。
(2) 進程執行了阻塞操做並進入睡眠
(3)進程中止(處於TASK_STOPPED 或TASK_TRACED狀態)或被殺死。
(4)進程經過調用系統調用sched_yield(),自願放棄CPU 。
(5)進程基於時間片輪轉的實時進程(SCHED_RR),並且用完了它的時間片。
基於時間片輪轉的實時進程是,不是真正的改變進程的優先級,而是改變進程的基本時間片的長度。因此基於時間片輪轉的進程調度,並不能保證高優先級的進程先運行。
下面是另外一種運行結果:
unix
|
能夠看出並無每一次都保證高優先級的線程先運行。