2012-11-21 40 views
13

POSIX XSH 2.8.4 Process Scheduling定義了線程和進程的調度屬性的行爲。指定sched_*接口會影響進程的調度屬性,而不是線程。這在以下段落中得到了澄清:瞭解POSIX和Linux/glibc sched_ *函數之間的差異

POSIX模型將「進程」視爲系統資源的集合,包括一個或多個可由操作系統在其控制的處理器上調度的線程。儘管一個進程具有自己的一組調度屬性,但它們對各個線程的調度行爲有間接影響(如果有的話),如下所述。

對於系統調度爭用範圍線程,進程調度屬性應具有在任一螺紋或專用於該螺紋底層內核調度實體的調度屬性或行爲沒有影響。

我對此的解讀是,其中只有「系統調度爭用範圍」支持系統(Linux的/ glibc的是這樣的系統)上,該sched_*功能應該絕對沒有可觀察到的效果。

這與Linux/glibc上當前行爲的實際情況相反,其中sched_*設置特定線程的調度屬性。

除了希望更好地瞭解一般這種情況下,我想我有這些關鍵問題:

  1. 是否有這種差異的理由的任何文件?

  2. 我的閱讀標準是否正確?特別是,對於我來說,sched_setparamsched_setscheduler在單線程應用程序中(主線程使用默認的調度策略(不能更改)以及系統爭用範圍)沒有效果,這似乎真的令人驚訝。

  3. 標準sched_*函數的用處是什麼?在我看來,它們對大多數實現沒有任何影響,即使對支持進程競爭範圍的實現影響也很小。有人可以描述他們的使用目的嗎?

+2

如果這不是StackOverflow,那麼火焰戰將會在這裏開始。 – ssice

回答

0

爲在Linux中sched_setparam等行爲的理由是,線程是由clone(2)系統調用,參見創建事實過程glibc/nptl/sysdeps/pthread/createthread.c

+2

「線程實際上是流程」是一個古老的說法,事實上並非如此。進程是內核稱之爲「線程組」的部分,它們與線程完全不同。但是,在添加這些接口時,你所說的可能仍然是「真實的」;讓他們做錯事情的理由可能只是現有的應用程序使用情況。然而,給NPTL解決了LinuxThreads中大部分不正確的語義問題,似乎很奇怪,這個問題還沒有被修復...... –

+0

好吧,這個措辭聽起來不太好,確實,雖然它現在沒有更少(或更多)到LinuxThreads時代。無論如何,在內核中沒有明確的「具有單線程的線程組」,並且「fork」和「pthread_create」都到達內核中相同的「do_fork」函數,該函數創建了相同的'struct task_struct '。 – chill

+1

我同意Linux中沒有進程(線程組)的調度屬性。這就是爲什麼NPTL省略進程調度爭用範圍(順便說一句,POSIX使其成爲可選)。我沒有得到的是爲什麼當這些函數看起來被指定爲接近或完全空操作時,這些函數正在改變單個線程的調度屬性。 –

1

我相信原因在於自從NPTL實施之前就已經是這種方式了,沒有人爲內核貢獻線程組範圍的調度屬性支持,所以這些功能仍然在做他們一直以來做的事情。

可能是因爲,正如你指出的那樣,POSIX指定它們的方式在沒有進程爭用範圍的情況下根本不會有用...... hellip;