linux線程淺析)

http://hi.baidu.com/_kouu/blog/item/49c820ffe237b83b5c60083f.html

關於linux線程

在許多經典的作業系統教科書中, 總是把進程定義為程式的執行執行個體, 它並不執行什麼, 只是維護應用程式所需的各種資源. 而線程則是真正的執行實體. 
為了讓進程完成一定的工作, 進程必須至少包含一個線程. 1.

進程所維護的是程式所包含的資源(靜態資源), 如: 地址空間, 開啟的檔案控制代碼集, 檔案系統狀態, 訊號處理handler, 等;
線程所維護的運行相關的資源(動態資源), 如: 運行棧, 調度相關的控制資訊, 待處理的訊號集, 等;

然而, 一直以來, linux核心並沒有線程的概念. 每一個執行實體都是一個task_struct結構, 通常稱之為進程. 2.

進程是一個執行單元, 維護著執行相關的動態資源. 同時, 它又引用著程式所需的靜態資源.
通過系統調用clone建立子進程時, 可以有選擇性地讓子進程共用父進程所引用的資源. 這樣的子進程通常稱為輕量級進程. 

linux上的線程就是基於輕量級進程, 由使用者態的pthread庫實現的.
使用pthread以後, 在使用者看來, 每一個task_struct就對應一個線程, 而一組線程以及它們所共同引用的一組資源就是一個進程.

但是, 一組線程並不僅僅是引用同一組資源就夠了, 它們還必須被視為一個整體.
對此, POSIX標準提出了如下要求:
1, 查看進程列表的時候, 相關的一組task_struct應當被展現為列表中的一個節點;
2, 發送給這個"進程"的訊號(對應kill系統調用), 將被對應的這一組task_struct所共用, 並且被其中的任意一個"線程"處理;
3, 發送給某個"線程"的訊號(對應pthread_kill), 將只被對應的一個task_struct接收, 並且由它自己來處理;
4, 當"進程"被停止或繼續時(對應SIGSTOP/SIGCONT訊號), 對應的這一組task_struct狀態將改變;
5, 當"進程"收到一個致命訊號(比如由於段錯誤收到SIGSEGV訊號), 對應的這一組task_struct將全部退出;
6, 等等(以上可能不夠全);

linuxthreads

在linux 2.6以前, pthread線程庫對應的實現是一個名叫linuxthreads的lib. 
linuxthreads利用前面提到的輕量級進程來實現線程, 但是對於POSIX提出的那些要求, linuxthreads除了第5點以外, 都沒有實現(實際上是無能為力):
1, 如果運行了A程式, A程式建立了10個線程, 那麼在shell下執行ps命令時將看到11個A進程, 而不是1個(注意, 也不是10個, 下面會解釋);
2, 不管是kill還是pthread_kill, 訊號只能被一個對應的線程所接收;
3, SIGSTOP/SIGCONT訊號只對一個線程起作用;

還好linuxthreads實現了第5點, 我認為這一點是最重要的. 如果某個線程"掛"了, 整個進程還在若無其事地運行著, 可能會出現很多的不一致狀態. 進程將不是一個整體, 而線程也不能稱為線程. 
或許這也是為什麼linuxthreads雖然與POSIX的要求差距甚遠, 卻能夠存在, 並且還被使用了好幾年的原因吧~
但是, linuxthreads為了實現這個"第5點", 還是付出了很多代價, 並且創造了linuxthreads本身的一大效能瓶頸.

接下來要說說, 為什麼A程式建立了10個線程, 但是ps時卻會出現11個A進程了. 因為linuxthreads自動建立了一個管理線程. 上面提到的"第5點"就是靠管理線程來實現的.
當程式開始運行時, 並沒有管理線程存在(因為儘管程式已經連結了pthread庫, 但是未必會使用多線程). 
程式第一次調用pthread_create時, linuxthreads探索管理線程不存在, 於是建立這個管理線程. 這個管理線程是進程中的第一個線程(主線程)的兒子.
然後在pthread_create中, 會通過pipe向管理線程發送一個命令, 告訴它建立線程. 即是說, 除主線程外, 所有的線程都是由管理線程來建立的, 管理線程是它們的父親.
於是, 當任何一個子線程退出時, 管理線程將收到SIGUSER1訊號(這是在通過clone建立子線程時指定的). 管理線程在對應的sig_handler中會判斷子線程是否正常退出, 如果不是, 則殺死所有線程, 然後自殺.
那麼, 主線程怎麼辦呢? 主線程是管理線程的父親, 其退出時並不會給管理線程發訊號. 於是, 在管理線程的主迴圈中通過getppid檢查父進程的ID號, 如果ID號是1, 說明父親已經退出, 並把自己託管給了init進程(1號進程). 這時候, 管理線程也會殺掉所有子線程, 然後自殺. 那麼, 如果主線程是調用pthread_exit主動退出的呢? 按照posix的標準，這種情況下其他子線程是應該繼續啟動並執行. 於是, 在linuxthreads中, 主線程調用pthread_exit以後並不會真正退出, 而是會在pthread_exit函數中阻塞等待所有子線程都退出了, pthread_exit才會讓主線程退出. (在這個等等過程中, 主線程一直處於睡眠狀態.)

可見, 線程的建立與銷毀都是通過管理線程來完成的, 於是管理線程就成了linuxthreads的一個效能瓶頸. 
建立與銷毀需要一次處理序間通訊, 一次環境切換之後才能被管理線程執行, 並且多個請求會被管理線程串列地執行.

NPTL

到了linux 2.6, glibc中有了一種新的pthread線程庫--NPTL(Native POSIX Threading Library). 
NPTL實現了前面提到的POSIX的全部5點要求. 但是, 實際上, 與其說是NPTL實現了, 不如說是linux核心實現了.

在linux 2.6中, 核心有了線程組的概念, task_struct結構中增加了一個tgid(thread group id)欄位. 
如果這個task是一個"主線程", 則它的tgid等於pid, 否則tgid等於進程的pid(即主線程的pid).
在clone系統調用中, 傳遞CLONE_THREAD參數就可以把新進程的tgid設定為父進程的tgid(否則新進程的tgid會設為其自身的pid).
類似的XXid在task_struct中還有兩個：task->signal->pgid儲存進程組的打頭進程的pid、task->signal->session儲存會話打頭進程的pid。通過這兩個id來關聯進程組和會話。

有了tgid, 核心或相關的shell程式就知道某個tast_struct是代表一個進程還是代表一個線程, 也就知道在什麼時候該展現它們, 什麼時候不該展現(比如在ps的時候, 線程就不要展現了).
而getpid(擷取進程ID)系統調用返回的也是tast_struct中的tgid, 而tast_struct中的pid則由gettid系統調用來返回.
在執行ps命令的時候不展現子線程，也是有一些問題的。比如程式a.out運行時，建立了一個線程。假設主線程的pid是10001、子線程是10002（它們的tgid都是10001）。這時如果你kill 10002，是可以把10001和10002這兩個線程一起殺死的，儘管執行ps命令的時候根本看不到10002這個進程。如果你不知道linux線程背後的故事，肯定會覺得遇到靈異事件了。

為了應付"發送給進程的訊號"和"發送給線程的訊號", task_struct裡面維護了兩套signal_pending, 一套是線程組共用的, 一套是線程專屬的.
通過kill發送的訊號被放線上程組共用的signal_pending中, 可以由任意一個線程來處理; 通過pthread_kill發送的訊號(pthread_kill是pthread庫的介面, 對應的系統調用中tkill)被放線上程專屬的signal_pending中, 只能由本線程來處理.

當線程停止/繼續, 或者是收到一個致命訊號時, 核心會將處理動作施加到整個線程組中.

NGPT

說到這裡, 也順便提一下NGPT(Next Generation POSIX Threads). 
上面提到的兩種線程庫使用的都是核心級線程(每個線程都對應核心中的一個調度實體), 這種模型稱為1:1模型(1個線程對應1個核心級線程);
而NGPT則打算實現M:N模型(M個線程對應N個核心級線程), 也就是說若干個線程可能是在同一個執行實體上實現的. 
線程庫需要在一個核心提供的執行實體上抽象出若干個執行實體, 並實現它們之間的調度. 這樣被抽象出來的執行實體稱為使用者級線程.
大體上, 這可以通過為每個使用者級線程分配一個棧, 然後通過longjmp的方式進行環境切換. (百度一下"setjmp/longjmp", 你就知道.)
但是實際上要處理的細節問題非常之多. 
目前的NGPT好像並沒有實現所有預期的功能, 並且暫時也不準備去實現.

使用者級線程的切換顯然要比核心級線程的切換快一些, 前者可能只是一個簡單的長跳轉, 而後者則需要儲存/裝載寄存器, 進入然後退出核心態. (進程切換則還需要切換地址空間等.)
而使用者級線程則不能享受多處理器, 因為多個使用者級線程對應到一個核心級線程上, 一個核心級線程在同一時刻只能運行在一個處理器上.
不過, M:N的執行緒模式畢竟提供了這樣一種手段, 可以讓不需要並存執行的線程運行在一個核心級線程對應的若干個使用者級線程上, 可以節省它們的切換開銷.

據說一些類UNIX系統(如Solaris)已經實現了比較成熟的M:N執行緒模式, 其效能比起linux的線程還是有著一定的優勢.