首先從OS設(shè)計原理上闡明三種線程：內(nèi)核線程、輕量級進程、用戶線程

內(nèi)核線程

內(nèi)核線程就是內(nèi)核的分身，一個分身可以處理一件特定事情。這在處理異步事件如異步IO時特別有用。內(nèi)核線程的使用是廉價的，唯一使用的資源就是內(nèi)核棧和上下文切換時保存寄存器的空間。支持多線程的內(nèi)核叫做多線程內(nèi)核(Multi-Threads kernel )。

輕量級進程

輕量級線程(LWP)是一種由內(nèi)核支持的用戶線程。它是基于內(nèi)核線程的高級抽象，因此只有先支持內(nèi)核線程，才能有LWP。每一個進程有一個或多個Lwps，每個LWP由一個內(nèi)核線程支持。這種模型實際上就是恐龍書上所提到的一對一線程模型。在這種實現(xiàn)的操作系統(tǒng)中，LWP就是用戶線程。

由于每個LWP都與一個特定的內(nèi)核線程關(guān)聯(lián)，因此每個LWP都是一個獨立的線程調(diào)度單元。即使有一個LWP在系統(tǒng)調(diào)用中阻塞，也不會影響整個進程的執(zhí)行。

輕量級進程具有局限性。首先，大多數(shù)LWP的操作，如建立、析構(gòu)以及同步，都需要進行系統(tǒng)調(diào)用。系統(tǒng)調(diào)用的代價相對較高：需要在user mode和kernel mode中切換。其次，每個LWP都需要有一個內(nèi)核線程支持，因此LWP要消耗內(nèi)核資源（內(nèi)核線程的棧空間）。因此一個系統(tǒng)不能支持大量的LWP。

注：

LWP 的術(shù)語是借自于 SVR4/MP 和 Solaris 2.x 。有些系統(tǒng)將 LWP 稱為虛擬處理器。而將之稱為輕量級進程的原因可能是：在內(nèi)核線程的支持下， LWP 是獨立的調(diào)度單元，就像普通的進程一樣。所以 LWP 的最大特點還是每個 LWP 都有一個內(nèi)核線程支持。

用戶線程

LWP雖然本質(zhì)上屬于用戶線程，但LWP線程庫是建立在內(nèi)核之上的，LWP的許多操作都要進行系統(tǒng)調(diào)用，因此效率不高。而這里的用戶線程指的是完全建立在用戶空間的線程庫，用戶線程的建立，同步，銷毀，調(diào)度完全在用戶空間完成，不需要內(nèi)核的幫助。因此這種線程的操作是極其快速的且低消耗的。

上圖是最初的一個用戶線程模型，從中可以看出，進程中包含線程，用戶線程在用戶空間中實現(xiàn)，內(nèi)核并沒有直接對用戶線程進程調(diào)度，內(nèi)核的調(diào)度對象和傳統(tǒng)進程一樣，還是進程本身，內(nèi)核并不知道用戶線程的存在。用戶線程之間的調(diào)度由在用戶空間實現(xiàn)的線程庫實現(xiàn)。

這種模型對應(yīng)著恐龍書中提到的多對一線程模型，其缺點是一個用戶線程如果阻塞在系統(tǒng)調(diào)用中，則整個進程都將會阻塞。

加強版的用戶線程——用戶線程+LWP

這種模型對應(yīng)著恐龍書中多對多模型。用戶線程庫還是完全建立在用戶空間中，因此用戶線程的操作還是很廉價，因此可以建立任意多需要的用戶線程。操作系統(tǒng)提供了 LWP 作為用戶線程和內(nèi)核線程之間的橋梁。 LWP 還是和前面提到的一樣，具有內(nèi)核線程支持，是內(nèi)核的調(diào)度單元，并且用戶線程的系統(tǒng)調(diào)用要通過 LWP ，因此進程中某個用戶線程的阻塞不會影響整個進程的執(zhí)行。用戶線程庫將建立的用戶線程關(guān)聯(lián)到 LWP 上， LWP 與用戶線程的數(shù)量不一定一致。當內(nèi)核調(diào)度到某個 LWP 上時，此時與該 LWP 關(guān)聯(lián)的用戶線程就被執(zhí)行。

很多文獻中都認為輕量級進程就是線程，實際上這種說法并不完全正確，從前面的分析中可以看到，只有在用戶線程完全由輕量級進程構(gòu)成時，才可以說輕量級進程就是線程。

linuxThreads

　　所實現(xiàn)的就是基于核心輕量級進程的"一對一"線程模型，一個線程實體對應(yīng)一個核心輕量級進程，而線程之間的管理在核外函數(shù)庫（我們常用的pthread庫）中實現(xiàn)。 一直以來, linux內(nèi)核并沒有線程的概念. 每一個執(zhí)行實體都是一個task_struct結(jié)構(gòu), 通常稱之為進程.

　　進程是一個執(zhí)行單元, 維護著執(zhí)行相關(guān)的動態(tài)資源. 同時, 它又引用著程序所需的靜態(tài)資源.通過系統(tǒng)調(diào)用clone創(chuàng)建子進程時, 可以有選擇性地讓子進程共享父進程所引用的資源. 這樣的子進程通常稱為輕量級進程，如上文所述，又叫內(nèi)核線程。

[插曲]說下fork和vfork的區(qū)別
　　fork時，子進程是父進程的一個拷貝。子進程從父進程那得到了數(shù)據(jù)段和堆棧段，但不是與父進程共享而是單獨分配內(nèi)存。然而最初狀態(tài)是共享的，linux下使用了寫時復(fù)制技術(shù)，剛開始共享父進程的數(shù)據(jù)段，在寫數(shù)據(jù)段的時候才進行復(fù)制，以fork為例，最終共享的資源就是task_struct、系統(tǒng)空間堆棧（copy_thread）、頁面表等。　　vfork時，因為實現(xiàn)為子進程先執(zhí)行，所以是不拷貝（沒必要）父進的虛存空間，也就是用戶空間堆棧，clone(clone_vfork|clone_vm|sigchld,0)，指明的參數(shù)是不會拷貝，注定共享的。因為現(xiàn)在的fork都是寫實拷貝，所以vfork的優(yōu)勢便不明顯了——只是不用向vfork那樣拷貝頁表。另外，內(nèi)核都是優(yōu)先讓子進程先執(zhí)行，考慮到調(diào)度問題，fork不保證；但vfork可保證這點　　2.4內(nèi)核 do_dork是fork/vfork/clone系統(tǒng)調(diào)用的共同代碼，其核心流程如下：　　1) 默認對所有資源進行共享暫不復(fù)制;　　2) 如果flags未指定共享（相應(yīng)位為0），則進行深層次復(fù)制。包括，file,fs,sighand,mm。   　　以CLONE_FILES為例，對fork而言為1，也就是必須復(fù)制兩份files，這樣父子進程才有獨立上下文（各自獨立lseek不影響，但是文件指針肯定還是指向一個）;但是對于vfork，這個標志為1，也就是父子進程共享文件上下文（注意這里不是共享文件指針，連上下文都共享！也就是子進程lseek會改變父進程讀寫位置），這豈不亂套（類似還有vfork的CLONE_VM標志）！別擔心，do_fork中會保證vfork時候，自進程先執(zhí)行完！   　　特殊說下，mm資源即使是非共享的，即CLONE_VM=1（fork如此），也不馬上復(fù)制，而是復(fù)制頁面表后，把也表項設(shè)置為寫保護，這樣無論誰寫，屆時都會再復(fù)制一份出來，這才完成的資源的獨立——對fork而言。　　3) 復(fù)制系統(tǒng)堆棧（區(qū)別于用戶空間VM）
　
用戶態(tài)線程由pthread庫實現(xiàn)，使用pthread以后, 在用戶看來, 每一個task_struct就對應(yīng)一個線程, 而一組線程以及它們所共同引用的一組資源就是一個進程.　　但是, 一組線程并不僅僅是引用同一組資源就夠了, 它們還必須被視為一個整體.
POSIX線程實現(xiàn)基于如下要求:------線程的總要求：1, 查看進程列表的時候, 相關(guān)的一組task_struct應(yīng)當被展現(xiàn)為列表中的一個節(jié)點;2, 發(fā)送給這個"進程"的信號(對應(yīng)kill系統(tǒng)調(diào)用), 將被對應(yīng)的這一組task_struct所共享, 并且被其中的任意一個"線程"處理;3, 發(fā)送給某個"線程"的信號(對應(yīng)pthread_kill), 將只被對應(yīng)的一個task_struct接收, 并且由它自己來處理;4, 當"進程"被停止或繼續(xù)時(對應(yīng)SIGSTOP/SIGCONT信號), 對應(yīng)的這一組task_struct狀態(tài)將改變;5, 當"進程"收到一個致命信號(比如由于段錯誤收到SIGSEGV信號), 對應(yīng)的這一組task_struct將全部退出;6, 以上可能不全;
　　在linux 2.6以前, pthread線程庫對應(yīng)的實現(xiàn)是一個名叫l(wèi)inuxthreads的lib. linuxthreads利用前面提到的輕量級進程來實現(xiàn)線程, 但是對于POSIX提出的那些要求, linuxthreads 除了第5點以外, 都沒有實現(xiàn)(實際上是無能為力):1, 如果運行了A程序, A程序創(chuàng)建了10個線程, 那么在shell下執(zhí)行ps命令時將看到11個A進程, 而不是1個(注意, 也不是10個, 下面會解釋);2, 不管是kill還是pthread_kill, 信號只能被一個對應(yīng)的線程所接收;3, SIGSTOP/SIGCONT信號只對一個線程起作用;
　　還好linuxthreads實現(xiàn)了第5點, 我認為這一點是最重要的. 如果某個線程"掛"了, 整個進程還在若無其事地運行著, 可能會出現(xiàn)很多的不一致狀態(tài). 進程將不是一個整體, 而線程也不能稱為線程. 或許這也是為什么linuxthreads雖然與POSIX的要求差距甚遠, 卻能夠存在, 并且還被使用了好幾年的原因吧。是, linuxthreads為了實現(xiàn)這個"第5點", 還是付出了很多代價,并且創(chuàng)造了linuxthreads本身的一大性能瓶頸.
　　接下來要說說, 為什么A程序創(chuàng)建了10個線程, 但是ps時卻會出現(xiàn)11個A進程了. 因為linuxthreads自動創(chuàng)建了一個管理線程. 上面提到的"第5點"就是靠管理線程來實現(xiàn)的.當程序開始運行時, 并沒有管理線程存在(因為盡管程序已經(jīng)鏈接了pthread庫, 但是未必會使用多線程). 程序第一次調(diào)用pthread_create時, linuxthreads發(fā)現(xiàn)管理線程不存在, 于是創(chuàng)建這個管理線程. 這個管理線程是進程中的第一個線程(主線程)的兒子.　　然后在pthread_create中, 會通過pipe向管理線程發(fā)送一個命令, 告訴它創(chuàng)建線程. 即是說, 除主線程外, 所有的線程都是由管理線程來創(chuàng)建的, 管理線程是它們的父親.于是, 當任何一個子線程退出時, 管理線程將收到SIGUSER1信號(這是在通過clone創(chuàng)建子線程時指定的). 管理線程在對應(yīng)的sig_handler中會判斷子線程是否正常退出, 如果不是, 則殺死所有線程, 然后自殺.　　那么, 主線程怎么辦呢? 主線程是管理線程的父親, 其退出時并不會給管理線程發(fā)信號. 于是, 在管理線程的主循環(huán)中通過getppid檢查父進程的ID號, 如果ID號是1, 說明父親已經(jīng)退出, 并把自己托管給了init進程(1號進程). 這時候, 管理線程也會殺掉所有子線程, 然后自殺. 那么, 如果主線程是調(diào)用pthread_exit主動退出的呢? 按照posix的標準，這種情況下其他子線程是應(yīng)該繼續(xù)運行的. 于是, 在linuxthreads中, 主線程調(diào)用pthread_exit以后并不會真正退出, 而是會在pthread_exit函數(shù)中阻塞等待所有子線程都退出了, pthread_exit才會讓主線程退出. (在這個等等過程中, 主線程一直處于睡眠狀態(tài).)
　　可見, 線程的創(chuàng)建與銷毀都是通過管理線程來完成的, 于是管理線程就成了linuxthreads的一個性能瓶頸. 創(chuàng)建與銷毀需要一次進程間通信, 一次上下文切換之后才能被管理線程執(zhí)行, 并且多個請求會被管理線程串行地執(zhí)行.
NPTL(Native POSIX Threading Library)
到了linux 2.6, glibc中有了一種新的pthread線程庫NPTL. NPTL實現(xiàn)了前面提到的POSIX的全部5點要求. 但是, 實際上, 與其說是NPTL實現(xiàn)了, 不如說是linux內(nèi)核實現(xiàn)了.
在linux 2.6中, 內(nèi)核有了線程組的概念, task_struct結(jié)構(gòu)中增加了一個tgid(thread group id)字段.如果這個task是一個"主線程", 則它的tgid等于pid, 否則tgid等于進程的pid(即主線程的pid),此外，每個線程有自己的pid。在clone系統(tǒng)調(diào)用中, 傳遞CLONE_THREAD參數(shù)就可以把新進程的tgid設(shè)置為父進程的tgid(否則新進程的tgid會設(shè)為其自身的pid).類似的XXid在task_struct中還有兩個：task->signal->pgid保存進程組的打頭進程的pid、task->signal->session保存會話打頭進程的pid。通過這兩個id來關(guān)聯(lián)進程組和會話。
　　有了tgid, 內(nèi)核或相關(guān)的shell程序就知道某個tast_struct是代表一個進程還是代表一個線程, 也就知道在什么時候該展現(xiàn)它們, 什么時候不該展現(xiàn)(比如在ps的時候, 線程就不要展現(xiàn)了).而getpid(獲取進程ID)系統(tǒng)調(diào)用返回的也是tast_struct中的tgid, 而tast_struct中的pid則由gettid系統(tǒng)調(diào)用來返回.在執(zhí)行ps命令的時候不展現(xiàn)子線程，也是有一些問題的。比如程序a.out運行時，創(chuàng)建了一個線程。假設(shè)主線程的pid是10001、子線程是10002（它們的tgid都是10001）。這時如果你kill 10002，是可以把10001和10002這兩個線程一起殺死的，盡管執(zhí)行ps命令的時候根本看不到10002這個進程。如果你不知道linux線程背后的故事，肯定會覺得遇到靈異事件了。
　　為了應(yīng)付"發(fā)送給進程的信號"和"發(fā)送給線程的信號", task_struct里面維護了兩套signal_pending, 一套是線程組共享的, 一套是線程獨有的.通過kill發(fā)送的信號被放在線程組共享的signal_pending中, 可以由任意一個線程來處理; 通過pthread_kill發(fā)送的信號(pthread_kill是pthread庫的接口, 對應(yīng)的系統(tǒng)調(diào)用中tkill)被放在線程獨有的signal_pending中, 只能由本線程來處理.
　　當線程停止/繼續(xù), 或者是收到一個致命信號時, 內(nèi)核會將處理動作施加到整個線程組中.
NGPT(Next Generation POSIX Threads)
　　上面提到的兩種線程庫使用的都是內(nèi)核級線程(每個線程都對應(yīng)內(nèi)核中的一個調(diào)度實體), 這種模型稱為1:1模型(1個線程對應(yīng)1個內(nèi)核級線程);而NGPT則打算實現(xiàn)M:N模型(M個線程對應(yīng)N個內(nèi)核級線程), 也就是說若干個線程可能是在同一個執(zhí)行實體上實現(xiàn)的.　　線程庫需要在一個內(nèi)核提供的執(zhí)行實體上抽象出若干個執(zhí)行實體, 并實現(xiàn)它們之間的調(diào)度. 這樣被抽象出來的執(zhí)行實體稱為用戶級線程.大體上, 這可以通過為每個用戶級線程分配一個棧, 然后通過longjmp的方式進行上下文切換. (百度一下"setjmp/longjmp", 你就知道.)　　但是實際上要處理的細節(jié)問題非常之多. 目前的NGPT好像并沒有實現(xiàn)所有預(yù)期的功能, 并且暫時也不準備去實現(xiàn).
　　用戶級線程的切換顯然要比內(nèi)核級線程的切換快一些, 前者可能只是一個簡單的長跳轉(zhuǎn), 而后者則需要保存/裝載寄存器, 進入然后退出內(nèi)核態(tài). (進程切換則還需要切換地址空間等).而用戶級線程則不能享受多處理器, 因為多個用戶級線程對應(yīng)到一個內(nèi)核級線程上, 一個內(nèi)核級線程在同一時刻只能運行在一個處理器上.不過, M:N的線程模型畢竟提供了這樣一種手段, 可以讓不需要并行執(zhí)行的線程運行在一個內(nèi)核級線程對應(yīng)的若干個用戶級線程上, 可以節(jié)省它們的切換開銷.
　　據(jù)說一些類UNIX系統(tǒng)(如Solaris)已經(jīng)實現(xiàn)了比較成熟的M:N線程模型, 其性能比起linux的線程還是有著一定的優(yōu)勢.
參考文獻：linux內(nèi)核設(shè)計與實現(xiàn) 3.4 線程在linux中的實現(xiàn)
　　　　　linux內(nèi)核源代碼情景分析 4.3
　　　　　APUE 8.4 VFORK函數(shù)
　　　　   linux內(nèi)核源代碼情景分析 4.3 系統(tǒng)調(diào)用fork vfork clone
　　　　　Linux 線程實現(xiàn)機制分析 http://www.ibm.com/developerworks/cn/linux/kernel/l-thread/　　　　　關(guān)于進程、線程和輕量級進程的一些筆記  http://www.cnitblog.com/tarius.wu/articles/2277.html