一.輕量級進程LWP
既然稱作輕量級進程，可見其本質仍然是進程，與普通進程相比，LWP與其它進程共享所有（或大部分）邏輯地址空間和系統資源，一個進程可以創建多個LWP，這樣它們共享大部分資源；LWP有它自己的進程標識符，並和其他進程有着父子關係；這是和類Unix操作系統的系統調用vfork()生成的進程一樣的。LWP由內核管理並像普通進程一樣被調度。Linux內核是支持LWP的典型例子。Linux內核在 2.0.x版本就已經實現了輕量進程，應用程序可以通過一個統一的clone()系統調用接口，用不同的參數指定創建輕量進程還是普通進程，通過參數決定子進程和父進程共享的資源種類和數量，這樣就有了輕重之分。在內核中， clone()調用經過參數傳遞和解釋後會調用do_fork()，這個核內函數同時也是fork()、vfork()系統調用的最終實現。
在大多數系統中，LWP與普通進程的區別也在於它只有一個最小的執行上下文和調度程序所需的統計信息，而這也是它之所以被稱爲輕量級的原因。
因爲LWP之間共享它們的大部分資源，所以它在某些應用程序就不適用了；這個時候就要使用多個普通的進程了。例如，爲了避免內存泄漏（a process can be replaced by another one）和實現特權分隔（processes can run under other credentials and have other permissions）。
標 題: Re: 爲啥linux的線程實現採用clone?
發信站: 水木社區 (Fri May 9 23:09:43 2014), 站內
難道你說的kernel 2.4？
現在的kernel，線程並不創建process，是真正意義上的線程，各個線程共享一個pid
【 在 youxia (遊俠) 的大作中提到: 】
: LINUX的線程都是輕量級進程。難道採用UNIX線程不好嗎？
二．Linux線程發展
這個對於理解Linux多線程很有幫助，可惜《深入理解Linux內核》這本書隻字未提，根本沒講Linux多線程的機理，至少我沒看懂。
一直以來, linux內核並沒有線程的概念. 每一個執行實體都是一個task_struct結構, 通常稱之爲進程. Linux內核在 2.0.x版本就已經實現了輕量進程，應用程序可以通過一個統一的clone()系統調用接口，用不同的參數指定創建輕量進程還是普通進程。在內核中， clone()調用經過參數傳遞和解釋後會調用do_fork()，這個核內函數同時也是fork()、vfork()系統調用的最終實現。後來爲了引入多線程，Linux2.0~2.4實現的是俗稱LinuxThreads的多線程方式，到了2.6，基本上都是NPTL的方式了。下面我們分別介紹。
模型一 ：LinuxThreads
注：以下內容主要參考“楊沙洲 (mailto:[email protected]?subject=Linux 線程實現機制分析&[email protected])國防科技大學計算機學院”的“Linux 線程實現機制分析”。
linux 2.6以前, pthread線程庫對應的實現是一個名叫linuxthreads的lib.這種實現本質上是一種LWP的實現方式，即通過輕量級進程來模擬線程，內核並不知道有線程這個概念，在內核看來，都是進程。
Linux採用的“一對一”的線程模型，即一個LWP對應一個線程。這個模型最大的好處是線程調度由內核完成了，而其他線程操作（同步、取消）等都是核外的線程庫函數完成的。
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中，專門爲每一個進程構造了一個管理線程，負責處理線程相關的管理工作。當進程第一次調用pthread_create()創建一個線程的時候就會創建並啓動管理線程。然後管理線程再來創建用戶請求的線程。也就是說，用戶在調用pthread_create後，先是創建了管理線程，再由管理線程創建了用戶的線程。
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號進程). 這時候, 管理線程也會殺掉所有子線程, 然後自殺.
可見, 線程的創建與銷燬都是通過管理線程來完成的, 於是管理線程就成了linuxthreads的一個性能瓶頸.
創建與銷燬需要一次進程間通信, 一次上下文切換之後才能被管理線程執行, 並且多個請求會被管理線程串行地執行.
這種通過LWP的方式來模擬線程的實現看起來還是比較巧妙的，但也存在一些比較嚴重的問題：
1）線程ID和進程ID的問題
按照POSIX的定義，同一進程的所有的線程應該共享同一個進程和父進程ID，而Linux的這種LWP方式顯然不能滿足這一點。
2）信號處理問題
異步信號是以進程爲單位分發的，而Linux的線程本質上每個都是一個進程，且沒有進程組的概念，所以某些缺省信號難以做到對所有線程有效，例如SIGSTOP和SIGCONT，就無法將整個進程掛起，而只能將某個線程掛起。
3）線程總數問題
LinuxThreads將每個進程的線程最大數目定義爲1024，但實際上這個數值還受到整個系統的總進程數限制，這又是由於線程其實是核心進程。
4)管理線程問題
管理線程容易成爲瓶頸，這是這種結構的通病；同時，管理線程又負責用戶線程的清理工作，因此，儘管管理線程已經屏蔽了大部分的信號，但一旦管理線程死亡，用戶線程就不得不手工清理了，而且用戶線程並不知道管理線程的狀態，之後的線程創建等請求將無人處理。
5)同步問題
LinuxThreads中的線程同步很大程度上是建立在信號基礎上的，這種通過內核複雜的信號處理機制的同步方式，效率一直是個問題。
6）其他POSIX兼容性問題
Linux中很多系統調用，按照語義都是與進程相關的，比如nice、setuid、setrlimit等，在目前的LinuxThreads中，這些調用都僅僅影響調用者線程。
7）實時性問題
線程的引入有一定的實時性考慮，但LinuxThreads暫時不支持，比如調度選項，目前還沒有實現。不僅LinuxThreads如此，標準的Linux在實時性上考慮都很少
模型二：NPTL
到了linux 2.6, glibc中有了一種新的pthread線程庫--NPTL(Native POSIX Threading Library).
本質上來說，NPTL還是一個LWP的實現機制，但相對原有LinuxThreads來說，做了很多的改進。下面我們看一下NPTL如何解決原有LinuxThreads實現機制的缺陷
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
上面提到的兩種線程庫使用的都是內核級線程(每個線程都對應內核中的一個調度實體), 這種模型稱爲1:1模型(1個線程對應1個內核級線程);
而NGPT則打算實現M:N模型(M個線程對應N個內核級線程), 也就是說若干個線程可能是在同一個執行實體上實現的.
線程庫需要在一個內核提供的執行實體上抽象出若干個執行實體, 並實現它們之間的調度. 這樣被抽象出來的執行實體稱爲用戶級線程.
大體上, 這可以通過爲每個用戶級線程分配一個棧, 然後通過longjmp的方式進行上下文切換. (百度一下"setjmp/longjmp", 你就知道.)
但是實際上要處理的細節問題非常之多. 目前的NGPT好像並沒有實現所有預期的功能, 並且暫時也不準備去實現.
用戶級線程的切換顯然要比內核級線程的切換快一些, 前者可能只是一個簡單的長跳轉, 而後者則需要保存/裝載寄存器, 進入然後退出內核態. (進程切換則還需要切換地址空間等.)
而用戶級線程則不能享受多處理器, 因爲多個用戶級線程對應到一個內核級線程上, 一個內核級線程在同一時刻只能運行在一個處理器上.
不過, M:N的線程模型畢竟提供了這樣一種手段, 可以讓不需要並行執行的線程運行在一個內核級線程對應的若干個用戶級線程上, 可以節省它們的切換開銷.據說一些類UNIX系統(如Solaris)已經實現了比較成熟的M:N線程模型, 其性能比起linux的線程還是有着一定的優勢.
Linux的另一種可選線程模型是IBM開發的NGPT(Next Generation Posix Threads for Linux)，它是基於GNU Pth（GNU Portable Threads）項目而實現的M:N模型(M個用戶態線程對應N個核心態線程)。
Linux Implementations of POSIX Threads——POSIX線程的Linux版實現
Next Generation POSIX Threads (NGPT)
基於M：N模型的linux線程庫，由IBM開發。性能介於LinuxThreads和NPTL，03年終止開發了～～
Linux Threads
Linux的一代功臣，2.6之前的kernel使用的線程庫，由Xavier Leroy開發的～～大致的實現過程是：通過clone系統調用，參數CLONE_VM | CLONE_FILES | CLONE_FS | CLONE_SIGHAND 分別用來指明共享創建者的VM虛擬內存（用戶空間）、文件描述符、文件系統相關屬性（umask，root directory等）、信號處理程序表和阻塞信號表和掛起信號表。kernel創建一個Manager Thread管理所有線程創建與結束等。實現內部使用real-time 實時Singal用來傳遞操作信息。另外，Linux Threads 與標準差異參見TLPI-33.5.1，這也是它被NPTL取代的原因。
NPTL (Native POSIX Threads Library)
Kernel2.6沿用至今，Linux Threads的繼承者，有Ulrich Drepper 和 Ingo Molnar開發，這是他們的關於NPTL實現的論文草稿，他們供職於Redhat。NPTL性能遠高於Linux Threads，並且更加符合Posix Thread標準。需要內核的改動支持，所以2.2與2.4的內核不支持NPTL。
