一、線程有3種模型，分別是N:1用戶線程模型，1:1核心線程模型和N:M混合線程模型，posix thread屬于1:1模型。

（一）、N:1用戶線程模型

“線程實現”建立在“進程控制”機制之上，由用戶空間的程序庫來管理。OS內核完全不知道線程信息。這些線程稱為用戶空間線程。這些線程都工作在“進

程競爭范圍”（process contention scope）：各個線程在同一進程競爭“被調度的CPU時間”（但不直接和其他進程中的線程競爭）。

在N:1線程模型中，內核不干涉線程的任何生命活動，也不干涉同一進程中的線程環境切換。

在N:1線程模型中，一個進程中的多個線程只能調度到一個CPU，這種約束限制了可用的并行總量。

第二個缺點是如果某個線程執行了一個“阻塞式”操作（如read），那么，進程中的所有線程都會阻塞，直至那個操作結束。為此，一些線程的實現是為

這些阻塞式函數提供包裝器，用非阻塞版本替換這些系統調用，以消除這種限制。

（二）、1:1核心線程模型?pthread線程庫--NPTL(Native POSIX Threading Library)

在1:1核心線程模型中，應用程序創建的每一個線程（也有書稱為LWP）都由一個核心線程直接管理。OS內核將每一個核心線程都調到系統CPU上，

因此，所有線程都工作在“系統競爭范圍”（system contention scope）：線程直接和“系統范圍”內的其他線程競爭。

這種線程的創建與調度由內核完成，因為這種線程的系統開銷比較大（但一般來說，比進程開銷小）

（三）、N:M混合線程模型 ?NGPT(Next Generation POSIX Threads)

N:M混合線程模型提供了兩級控制，將用戶線程映射為系統的可調度體以實現并行，這個可調度體稱為輕量級進程（LWP:light weight process），LWP 再一一映射到核心線程。如下圖所示。OS內核將每一個核心線程都調到系統CPU上，因此，所有線程都工作在“系統競爭范圍”。

據說一些類UNIX系統(如Solaris)已經實現了比較成熟的M:N線程模型, 其性能比起linux的線程還是有著一定的優勢，但不能利用SMP結構。

按照2003年3月NGPT官方網站上的通知，NGPT考慮到NPTL日益廣泛地為人所接受，為避免不同的線程庫版本引起的混亂，今后將不再進行進一步開發，而今進行支持性的維護工作。也就是說，NGPT已經放棄與NPTL競爭下一代Linux POSIX線程庫標準。

二、posix 線程概述

我們知道，進程在各自獨立的地址空間中運行，進程之間共享數據需要用進程間通信機制，有些情況需要在一個進程中同時執行多個控制流程，這時候

線程就派上了用場，比如實現一個圖形界面的下載軟件，一方面需要和用戶交互，等待和處理用戶的鼠標鍵盤事件，另一方面又需要同時下載多個文

件，等待和處理從多個網絡主機發來的數據，這些任務都需要一個“等待-處理”的循環，可以用多線程實現，一個線程專門負責與用戶交互，另外幾個線

程每個線程負責和一個網絡主機通信。

以前我們講過，main函數和信號處理函數是同一個進程地址空間中的多個控制流程，多線程也是如此，但是比信號處理函數更加靈活，信號處理函數的

控制流程只是在信號遞達時產生，在處理完信號之后就結束，而多線程的控制流程可以長期并存，操作系統會在各線程之間調度和切換，就像在多個進

程之間調度和切換一樣。由于同一進程的多個線程共享同一地址空間，因此Text Segment、Data Segment都是共享的，如果定義一個函數，在各線程

中都可以調用，如果定義一個全局變量，在各線程中都可以訪問到，除此之外，各線程還共享以下進程資源和環境：

文件描述符表

每種信號的處理方式（SIG_IGN、SIG_DFL或者自定義的信號處理函數）

當前工作目錄

用戶id和組id

但有些資源是每個線程各有一份的：

線程id

上下文，包括各種寄存器的值、程序計數器和棧指針

?？臻g

errno變量

信號屏蔽字

調度優先級

我們將要學習的線程庫函數是由POSIX標準定義的，稱為POSIX thread或者pthread。在Linux上線程函數位于libpthread共享庫中，因此在編譯時要加上-lpthread選項。

注：linux 2.6?以后的線程就是由用戶態的pthread庫實現的.使用pthread以后,?在用戶看來,?每一個task_struct就對應一個線程,?而一組線程以及它們所共同引用的一組資源就是一個進程.在linux 2.6中, 內核有了線程組的概念, task_struct結構中增加了一個tgid(thread group id)字段.?getpid(獲取進程ID)系統調用返回的也是tast_struct中的tgid, 而tast_struct中的pid則由gettid系統調用來返回。
當線程停止/繼續, 或者是收到一個致命信號時, 內核會將處理動作施加到整個線程組中。
比如程序a.out運行時，創建了一個線程。假設主線程的pid是10001、子線程是10002（它們的tgid都是10001）。這時如果你kill 10002，是可以把10001和10002這兩個線程一起殺死的，盡管執行ps命令的時候根本看不到10002這個進程。如果你不知道linux線程背后的故事，肯定會覺得遇到靈異事件了。

?

三、pthread 系列函數

（一）

功能：創建一個新的線程
原型 int pthread_create(pthread_t *thread, const pthread_attr_t *attr, void *(*start_routine)(void*), void *arg);
參數
thread:返回線程ID
attr:設置線程的屬性，attr為NULL表示使用默認屬性
start_routine:是個函數地址，線程啟動后要執行的函數
arg:傳給線程啟動函數的參數
返回值：成功返回0；失敗返回錯誤碼

錯誤檢查：

以前學過的系統函數都是成功返回0，失敗返回-1，而錯誤號保存在全局變量errno中，而pthread庫的函數都是通過返回值返回錯誤號，雖然每個線程也都有一個errno，但這是為了兼容其它函數接口而提供的，pthread庫本身并不使用它，通過返回值返回錯誤碼更加清晰。由于pthread_create的錯誤碼不保存在errno中，因此不能直接用perror(3)打印錯誤信息，可以先用strerror(3)把錯誤號轉換成錯誤信息再打印。

（二）

功能：線程終止
原型 void pthread_exit(void *value_ptr);
參數
value_ptr：value_ptr不要指向一個局部變量，因為當其它線程得到這個返回指針時線程函數已經退出了。
返回值：無返回值，跟進程一樣，線程結束的時候無法返回到它的調用者（自身）

如果需要只終止某個線程而不終止整個進程，可以有三種方法：

1、從線程函數return。這種方法對主線程不適用，從main函數return相當于調用exit，而如果任意一個線程調用了exit或_exit，則整個進程的所有線程都終止。

2、一個線程可以調用pthread_cancel 終止同一進程中的另一個線程。

3、線程可以調用pthread_exit終止自己。

（三）

功能：等待線程結束
原型 int pthread_join(pthread_t thread, void **value_ptr);
參數
thread:線程ID
value_ptr:它指向一個指針，后者指向線程的返回值
返回值：成功返回0；失敗返回錯誤碼

當pthread_create 中的 start_routine返回時，這個線程就退出了，其它線程可以調用pthread_join得到start_routine的返回值，類似于父進程調用wait(2)得到子進程的退出狀態。

調用該函數的線程將掛起等待，直到id為thread的線程終止。thread線程以不同的方法終止，通過pthread_join得到的終止狀態是不同的，總結如下：

1、如果thread線程通過return返回，value_ptr所指向的單元里存放的是thread線程函數的返回值。

2、如果thread線程被別的線程調用pthread_cancel異常終止掉，value_ptr所指向的單元里存放的是常數PTHREAD_CANCELED。

3、如果thread線程是自己調用pthread_exit終止的，value_ptr所指向的單元存放的是傳給pthread_exit的參數。

如果對thread線程的終止狀態不感興趣，可以傳NULL給value_ptr參數。

（四）

功能：返回線程ID
原型 pthread_t pthread_self(void);
返回值：成功返回線程id

在Linux上，pthread_t類型是一個地址值，屬于同一進程的多個線程調用getpid(2)可以得到相同的進程號，而調用pthread_self(3)得到的線程號各不相同。線程id只在當前進程中保證是唯一的，在不同的系統中pthread_t這個類型有不同的實現，它可能是一個整數值，也可能是一個結構體，也可能是一個地址，所以不能簡單地當成整數用printf打印。

（五）

功能：取消一個執行中的線程
原型 int pthread_cancel(pthread_t thread);
參數
thread:線程ID
返回值：成功返回0；失敗返回錯誤碼

一個新創建的線程默認取消狀態（cancelability state）是可取消的，取消類型（?cancelability type）是同步的，即在某個可取消點（?cancellation point，即在執行某些函數的時候）才會取消線程。具體可以man 一下。

相關函數?int pthread_setcancelstate(int state, int *oldstate); ?int pthread_setcanceltype(int type, int *oldtype); 為保證一個事務型處理邏輯的完整可以使用這兩個函數，如下舉例，主線程創建完線程睡眠一陣調用pthread_cancel，test是thread_function。

?

C++ Code?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

?

void?*test(void?*arg) { ????for?(int?i?=?0;?i?<?10;?i++) ????{ ????????pthread_setcancelstate(PTHREAD_CANCEL_DISABLE,?NULL); ????????printf("start:?%d;?",?i); ????????sleep(1); ????????printf("end:?%d\n",?i); ????????if?(i?>?7) ????????{ ????????????pthread_setcancelstate(PTHREAD_CANCEL_ENABLE,?NULL); ????????????pthread_testcancel(); ????????} ????} ????return?(void?*)0; }

就算我們在完成一次完整邏輯后不立即改回 PTHREAD_CANCEL_ENABLE，就算后續循環再次調用?PTHREAD_CANCEL_DISABLE 設置，其 "未決狀態" 依然會保留的。循環執行i=0~8 后，i=9時在sleep可取消點線程被中斷。

（六）

功能：將一個線程分離
原型 int pthread_detach(pthread_t thread);
參數
thread:線程ID
返回值：成功返回0；失敗返回錯誤碼

一般情況下，線程終止后，其終止狀態一直保留到其它線程調用pthread_join獲取它的狀態為止（僵線程）。但是線程也可以被置為detach狀態，這樣的線程一旦終止就立刻回收它占用的所有資源，而不保留終止狀態。不能對一個已經處于detach狀態的線程調用pthread_join，這樣的調用將返回EINVAL。對一個尚未detach的線程調用pthread_join或pthread_detach都可以把該線程置為detach狀態，也就是說，不能對同一線程調用兩次pthread_join，或者如果已經對一個線程調用了pthread_detach就不能再調用pthread_join了。

這個函數既可以在主線程中調用，也可以在thread_function里面調用。

在主線程中通過線程屬性也可以達到同樣的效果，如下：

?

C++ Code?

1 2 3 4 5 6 7

?

pthread_attr_t?attr; pthread_attr_init(&attr); pthread_attr_setdetachstate(&attr,?PTHREAD_CREATE_DETACHED); pthread_t?tid; pthread_create(&tid,?&attr,?test,?"a");?//?test?is?thread_function sleep(3); pthread_attr_destroy(&attr);

下面寫個程序走一下這些函數：

?

C++ Code?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63

?

#include<stdio.h> #include<stdlib.h> #include<sys/ipc.h> #include<sys/msg.h> #include<sys/types.h> #include<unistd.h> #include<errno.h> #include<pthread.h> #include<string.h> #define?ERR_EXIT(m)?\ ????do?{?\ ????????perror(m);?\ ????????exit(EXIT_FAILURE);?\ ????}?while(0) void?*routine(void?*arg) { ????int?i; ????for?(i?=?0;?i?<?20;?i++) ????{ ????????printf("B"); ????????fflush(stdout); ????????usleep(20); ????????/* ????????????if?(i?==?3) ????????????????pthread_exit("ABC"); ????????????*/ ????} ????return?"DEF"; } int?main(void) { ????pthread_t?tid; ????int?ret; ????if?((ret?=?pthread_create(&tid,?NULL,?routine,?NULL))?!=?0) ????{ ????????fprintf(stderr,?"pthread?create:?%s\n",?strerror(ret)); ????????exit(EXIT_FAILURE); ????} ????int?i; ????for?(i?=?0;?i?<?20;?i++) ????{ ????????printf("A"); ????????fflush(stdout); ????????usleep(20); ????} ????void?*value; ????if?((ret?=?pthread_join(tid,?&value))?!=?0) ????{ ????????fprintf(stderr,?"pthread?create:?%s\n",?strerror(ret)); ????????exit(EXIT_FAILURE); ????} ????printf("\n"); ????printf("return?msg=%s\n",?(char?*)value); ????return?0; }

?

創建一個線程，主線程打印A，新線程打印B，主線程調用pthread_join 等待新線程退出，打印退出值。

simba@ubuntu:~/Documents/code/linux_programming/UNP/pthread$ ./pthread_create?
ABAABABABABABABABABABABABABAABABBABABABB
return msg=DEF

在新線程中也可調用pthread_exit 退出。

四、簡單的多線程服務器端程序

在將socket 編程的時候曾經使用fork 多進程的方式來實現并發，現在嘗試使用多線程方式來實現：

?

C++ Code?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96

?

#include?<unistd.h> #include?<sys/types.h> #include?<sys/socket.h> #include?<netinet/in.h> #include?<arpa/inet.h> #include?<pthread.h> #include?<stdlib.h> #include?<stdio.h> #include?<errno.h> #include?<string.h> #define?ERR_EXIT(m)?\ ????????do?\ ????????{?\ ????????????????perror(m);?\ ????????????????exit(EXIT_FAILURE);?\ ????????}?while(0) void?echo_srv(int?conn) { ????char?recvbuf[1024]; ????while?(1) ????{ ????????memset(recvbuf,?0,?sizeof(recvbuf)); ????????int?ret?=?read(conn,?recvbuf,?sizeof(recvbuf)); ????????if?(ret?==?0) ????????{ ????????????printf("client?close\n"); ????????????break; ????????} ????????else?if?(ret?==?-1) ????????????ERR_EXIT("read"); ????????fputs(recvbuf,?stdout); ????????write(conn,?recvbuf,?ret); ????} close(conn); } void?*thread_routine(void?*arg) { ????/*?主線程沒有調用pthread_join等待線程退出?*/ ????pthread_detach(pthread_self());?//剝離線程，避免產生僵線程 ????/*int?conn?=?(int)arg;*/ ????int?conn?=?*((int?*)arg); ????free(arg); ????echo_srv(conn); ????printf("exiting?thread?...\n"); ????return?NULL; } int?main(void) { ????int?listenfd; ????if?((listenfd?=?socket(PF_INET,?SOCK_STREAM,?IPPROTO_TCP))?<?0) ????????ERR_EXIT("socket"); ????struct?sockaddr_in?servaddr; ????memset(&servaddr,?0,?sizeof(servaddr)); ????servaddr.sin_family?=?AF_INET; ????servaddr.sin_port?=?htons(5188); ????servaddr.sin_addr.s_addr?=?htonl(INADDR_ANY); ????int?on?=?1; ????if?(setsockopt(listenfd,?SOL_SOCKET,?SO_REUSEADDR,?&on,?sizeof(on))?<?0) ????????ERR_EXIT("setsockopt"); ????if?(bind(listenfd,?(struct?sockaddr?*)&servaddr,?sizeof(servaddr))?<?0) ????????ERR_EXIT("bind"); ????if?(listen(listenfd,?SOMAXCONN)?<?0) ????????ERR_EXIT("listen"); ????struct?sockaddr_in?peeraddr; ????socklen_t?peerlen?=?sizeof(peeraddr); ????int?conn; ????while?(1) ????{ ????????if?((conn?=?accept(listenfd,?(struct?sockaddr?*)&peeraddr,?&peerlen))?<?0) ????????????ERR_EXIT("accept"); ????????printf("ip=%s?port=%d\n",?inet_ntoa(peeraddr.sin_addr),?ntohs(peeraddr.sin_port)); ????????pthread_t?tid; ????????//??????int?ret; ????????/*pthread_create(&tid,?NULL,?thread_routine,?(void*)&conn);*/?//?race?condition問題，竟態問題 ????????int?*p?=?malloc(sizeof(int)); ????????*p?=?conn; ????????pthread_create(&tid,?NULL,?thread_routine,?p); ????????/* ????????????????if?((ret?=?pthread_create(&tid,?NULL,?thread_routine,?(void*)conn))?!=?0)?//64位系統時指針不是4個字節，不可移植 ????????????????{ ????????????????????fprintf(stderr,?"pthread_create:%s\n",?strerror(ret)); ????????????????????exit(EXIT_FAILURE); ????????????????} ????????*/ ????}

?

程序邏輯并不復雜，一旦accept 返回一個已連接套接字，就創建一個新線程對其服務，在每個新線程thread_routine 中調用pthread_detach 剝離線程，我們的主線程不能調用pthread_join 等待這些新線程的退出，因為還要返回while 循環開頭去在accept 中阻塞監聽。

如果使用pthread_create(&tid, NULL, thread_routine, (void*)&conn); 存在的問題是如果accept 再次返回一個已連接套接字，而此時thread_routine 函數還沒取走conn 時，可能會讀取到已經被更改的conn 值。

如果使用 ?pthread_create(&tid, NULL, thread_routine, (void*)conn); 存在的問題是在64位系統中指針不是4個字節而是8個字節，即不可移植 性。

使用上述未被注釋的做法，每次返回一個conn，就malloc 一塊內存存放起來，在thread_routine 函數中去讀取即可。

開多個客戶端，可以看到正常服務。

后記：其實 pthread 系列函數也可以應用于進程間加鎖，怎么應用到多進程場合呢，被多個進程共享呢？

很簡單，首先需要設置互斥鎖的進程間共享屬性：

?

?

C++ Code?

1 2 3 4

?

int?pshared); pthread_mutexattr_t?mattr; pthread_mutexattr_init(&mattr); pthread_mutexattr_setpshared(&mattr,?PTHREAD_PROCESS_SHARED);

其次，為了達到多進程共享的需要，互斥鎖對象需要創建在共享內存中。

最后，需要注意的是，并不是所有Linux系統都支持這個特性，程序里需要檢查是否定義了_POSIX_SHARED_MEMORY_OBJECTS宏，只有定義了才能用這種方式實現進程間互斥鎖。

參考：

《linux c 編程一站式學習》

《UNP》

《APUE》

http://www.ibm.com/developerworks/cn/linux/l-cn-mthreadps/index.html

http://www.ibm.com/developerworks/cn/linux/kernel/l-thread/

?

?

?

?

Linux 的多線程編程的高效開發經驗

?

?

背景

?

Linux 平臺上的多線程程序開發相對應其他平臺（比如 Windows）的多線程 API 有一些細微和隱晦的差別。不注意這些 Linux 上的一些開發陷阱，常常會導致程序問題不窮，死鎖不斷。本文中我們從 5 個方面總結出 Linux 多線程編程上的問題，并分別引出相關改善的開發經驗，用以避免這些的陷阱。我們希望這些經驗可以幫助讀者們能更好更快的熟悉 Linux 平臺的多線程編程。

?

我們假設讀者都已經很熟悉 Linux 平臺上基本的線程編程的 Pthread 庫 API 。其他的第三方用以線程編程的庫，如 boost，將不會在本文中提及。本文中主要涉及的題材包括線程開發中的線程管理，互斥變量，條件變量等。進程概念將不會在本文中涉及。

?

Linux 上線程開發 API 的概要介紹

?

多線程開發在 Linux 平臺上已經有成熟的 Pthread 庫支持。其涉及的多線程開發的最基本概念主要包含三點：線程，互斥鎖，條件。其中，線程操作又分線程的創建，退出，等待 3 種?；コ怄i則包括 4 種操作，分別是創建，銷毀，加鎖和解鎖。條件操作有 5 種操作：創建，銷毀，觸發，廣播和等待。其他的一些線程擴展概念，如信號燈等，都可以通過上面的三個基本元素的基本操作封裝出來。

?

線程，互斥鎖，條件在 Linux 平臺上對應的 API 可以用表 1 歸納。為了方便熟悉 Windows 線程編程的讀者熟悉 Linux 多線程開發的 API，我們在表中同時也列出 Windows SDK 庫中所對應的 API 名稱。

?

表 1. 線程函數列表

?

對象操作Linux Pthread APIWindows SDK 庫對應 API

線程	創建	pthread_create	CreateThread
	退出	pthread_exit	ThreadExit
	等待	pthread_join	WaitForSingleObject
互斥鎖	創建	pthread_mutex_init	CreateMutex
	銷毀	pthread_mutex_destroy	CloseHandle
	加鎖	pthread_mutex_lock	WaitForSingleObject
	解鎖	pthread_mutex_unlock	ReleaseMutex
條件	創建	pthread_cond_init	CreateEvent
	銷毀	pthread_cond_destroy	CloseHandle
	觸發	pthread_cond_signal	SetEvent
	廣播	pthread_cond_broadcast	SetEvent / ResetEvent
	等待	pthread_cond_wait / pthread_cond_timedwait	SingleObjectAndWait

?

多線程開發在 Linux 平臺上已經有成熟的 Pthread 庫支持。其涉及的多線程開發的最基本概念主要包含三點：線程，互斥鎖，條件。其中，線程操作又分線程的創建，退出，等待 3 種?；コ怄i則包括 4 種操作，分別是創建，銷毀，加鎖和解鎖。條件操作有 5 種操作：創建，銷毀，觸發，廣播和等待。其他的一些線程擴展概念，如信號燈等，都可以通過上面的三個基本元素的基本操作封裝出來。

?

Linux 線程編程中的 5 條經驗

?

盡量設置 recursive 屬性以初始化 Linux 的互斥變量

?

互斥鎖是多線程編程中基本的概念，在開發中被廣泛使用。其調用次序層次清晰簡單：建鎖，加鎖，解鎖，銷毀鎖。但是需要注意的是，與諸如 Windows 平臺的互斥變量不同，在默認情況下，Linux 下的同一線程無法對同一互斥鎖進行遞歸加速，否則將發生死鎖。

?

所謂遞歸加鎖，就是在同一線程中試圖對互斥鎖進行兩次或兩次以上的行為。其場景在 Linux 平臺上的代碼可由清單 1 所示。

?

清單 1. Linux 重復對互斥鎖加鎖實例

?

// 通過默認條件建鎖 ????pthread_mutex_t *theMutex = new pthread_mutex_t; ????pthread_mutexattr_t attr; ????pthread_mutexattr_init(&attr); ????pthread_mutex_init(theMutex,&attr); ????pthread_mutexattr_destroy(&attr); ????// 遞歸加鎖 ????pthread_mutex_lock (theMutex); ????pthread_mutex_lock (theMutex); ????pthread_mutex_unlock (theMutex); ????pthread_mutex_unlock (theMutex);

?

在以上代碼場景中，問題將出現在第二次加鎖操作。由于在默認情況下，Linux 不允許同一線程遞歸加鎖，因此在第二次加鎖操作時線程將出現死鎖。

?

Linux 互斥變量這種奇怪的行為或許對于特定的某些場景會所有用處，但是對于大多數情況下看起來更像是程序的一個 bug 。畢竟，在同一線程中對同一互斥鎖進行遞歸加鎖在尤其是二次開發中經常會需要。

?

這個問題與互斥鎖的中的默認 recursive 屬性有關。解決問題的方法就是顯式地在互斥變量初始化時將設置起 recursive 屬性?；诖?#xff0c;以上代碼其實稍作修改就可以很好的運行，只需要在初始化鎖的時候加設置一個屬性。請看清單 2 。

?

清單 2. 設置互斥鎖 recursive 屬性實例

?

pthread_mutexattr_init(&attr); ????// 設置 recursive 屬性 ????pthread_mutexattr_settype(&attr,PTHREAD_MUTEX_RECURSIVE_NP); ????pthread_mutex_init(theMutex,&attr);

?

因此，建議盡量設置 recursive 屬性以初始化 Linux 的互斥鎖，這樣既可以解決同一線程遞歸加鎖的問題，又可以避免很多情況下死鎖的發生。這樣做還有一個額外的好處，就是可以讓 Windows 和 Linux 下讓鎖的表現統一。

?

注意 Linux 平臺上觸發條件變量的自動復位問題

?

條件變量的置位和復位有兩種常用模型：第一種模型是當條件變量置位（signaled）以后，如果當前沒有線程在等待，其狀態會保持為置位（signaled），直到有等待的線程進入被觸發，其狀態才會變為復位（unsignaled），這種模型的采用以 Windows 平臺上的 Auto-set Event 為代表。其狀態變化如圖 1 所示：

?

圖 1. Windows 的條件變量狀態變化流程

第二種模型則是 Linux 平臺的 Pthread 所采用的模型，當條件變量置位（signaled）以后，即使當前沒有任何線程在等待，其狀態也會恢復為復位（unsignaled）狀態。其狀態變化如圖 2 所示：

?

圖 2. Linux 的條件變量狀態變化流程

具體來說，Linux 平臺上 Pthread 下的條件變量狀態變化模型是這樣工作的：調用 pthread_cond_signal() 釋放被條件阻塞的線程時，無論存不存在被阻塞的線程，條件都將被重新復位，下一個被條件阻塞的線程將不受影響。而對于 Windows，當調用 SetEvent 觸發 Auto-reset 的 Event 條件時，如果沒有被條件阻塞的線程，那么條件將維持在觸發狀態，直到有新的線程被條件阻塞并被釋放為止。

?

這種差異性對于那些熟悉 Windows 平臺上的條件變量狀態模型而要開發 Linux 平臺上多線程的程序員來說可能會造成意想不到的尷尬結果。試想要實現一個旅客坐出租車的程序：旅客在路邊等出租車，調用條件等待。出租車來了，將觸發條件，旅客停止等待并上車。一個出租車只能搭載一波乘客，于是我們使用單一觸發的條件變量。這個實現邏輯在第一個模型下即使出租車先到，也不會有什么問題，其過程如圖 3 所示：

?

圖 3. 采用 Windows 條件變量模型的出租車實例流程

然而如果按照這個思路來在 Linux 上來實現，代碼看起來可能是清單 3 這樣。

?

清單 3. Linux 出租車案例代碼實例

?

…… ?// 提示出租車到達的條件變量 ?pthread_cond_t taxiCond; ?// 同步鎖 ?pthread_mutex_t taxiMutex; ?// 旅客到達等待出租車 ?void * traveler_arrive(void * name) { ????cout<< ” Traveler: ” <<(char *)name<< ” needs a taxi now! ” <<endl; ????pthread_mutex_lock(&taxiMutex); ????pthread_cond_wait (&taxiCond, &taxtMutex); ????pthread_mutex_unlock (&taxtMutex); ????cout<< ” Traveler: ” << (char *)name << ” now got a taxi! ” <<endl; ????pthread_exit( (void *)0 ); ?} ?// 出租車到達 ?void * taxi_arrive(void *name) { ????cout<< ” Taxi ” <<(char *)name<< ” arrives. ” <<endl; ????pthread_cond_signal(&taxtCond); ????pthread_exit( (void *)0 ); ?} ?void main() {? ????// 初始化 ????taxtCond= PTHREAD_COND_INITIALIZER; ????taxtMutex= PTHREAD_MUTEX_INITIALIZER; ????pthread_t thread; ????pthread_attr_t threadAttr; ????pthread_attr_init(&threadAttr); ????pthread_create(&thread, & threadAttr, taxt_arrive, (void *)( ” Jack ” )); ????sleep(1); ????pthread_create(&thread, &threadAttr, traveler_arrive, (void *)( ” Susan ” )); ????sleep(1); ????pthread_create(&thread, &threadAttr, taxi_arrive, (void *)( ” Mike ” )); ????sleep(1); ????return 0; ?}

?

好的，運行一下，看看結果如清單 4 。

?

清單 4. 程序結果輸出

?

Taxi Jack arrives. ????Traveler Susan needs a taxi now! ????Taxi Mike arrives. ????Traveler Susan now got a taxi.

?

其過程如圖 4 所示：

?

圖 4. 采用 Linux 條件變量模型的出租車實例流程

通過對比結果，你會發現同樣的邏輯，在 Linux 平臺上運行的結果卻完全是兩樣。對于在 Windows 平臺上的模型一， Jack 開著出租車到了站臺，觸發條件變量。如果沒顧客，條件變量將維持觸發狀態，也就是說 Jack 停下車在那里等著。直到 Susan 小姐來了站臺，執行等待條件來找出租車。 Susan 搭上 Jack 的出租車離開，同時條件變量被自動復位。

?

但是到了 Linux 平臺，問題就來了，Jack 到了站臺一看沒人，觸發的條件變量被直接復位，于是 Jack 排在等待隊列里面。來遲一秒的 Susan 小姐到了站臺卻看不到在那里等待的 Jack，只能等待，直到 Mike 開車趕到，重新觸發條件變量，Susan 才上了 Mike 的車。這對于在排隊系統前面的 Jack 是不公平的，而問題癥結是在于 Linux 平臺上條件變量觸發的自動復位引起的一個 Bug 。

?

條件變量在 Linux 平臺上的這種模型很難說好壞。但是在實際開發中，我們可以對代碼稍加改進就可以避免這種差異的發生。由于這種差異只發生在觸發沒有被線程等待在條件變量的時刻，因此我們只需要掌握好觸發的時機即可。最簡單的做法是增加一個計數器記錄等待線程的個數，在決定觸發條件變量前檢查下該變量即可。改進后 Linux 函數如清單 5 所示。

?

清單 5. Linux 出租車案例代碼實例

?

…… ?// 提示出租車到達的條件變量 ?pthread_cond_t taxiCond; ?// 同步鎖 ?pthread_mutex_t taxiMutex; ?// 旅客人數，初始為 0 ?int travelerCount=0; ?// 旅客到達等待出租車 ?void * traveler_arrive(void * name) { ????cout<< ” Traveler: ” <<(char *)name<< ” needs a taxi now! ” <<endl; ????pthread_mutex_lock(&taxiMutex); ????// 提示旅客人數增加 ????travelerCount++; ????pthread_cond_wait (&taxiCond, &taxiMutex); ????pthread_mutex_unlock (&taxiMutex); ????cout<< ” Traveler: ” << (char *)name << ” now got a taxi! ” <<endl; ????pthread_exit( (void *)0 ); ?} ?// 出租車到達 ?void * taxi_arrive(void *name) ?{ ????cout<< ” Taxi ” <<(char *)name<< ” arrives. ” <<endl; ?while(true) ?{ ????????pthread_mutex_lock(&taxiMutex); ????????// 當發現已經有旅客在等待時，才觸發條件變量 ????????if(travelerCount>0) ????????{ ????????????pthread_cond_signal(&taxtCond); ????????????pthread_mutex_unlock (&taxiMutex); ????????????break; ????????} ????????pthread_mutex_unlock (&taxiMutex); ????} ????pthread_exit( (void *)0 ); ?}

?

因此我們建議在 Linux 平臺上要出發條件變量之前要檢查是否有等待的線程，只有當有線程在等待時才對條件變量進行觸發。

?

注意條件返回時互斥鎖的解鎖問題

?

在 Linux 調用 pthread_cond_wait 進行條件變量等待操作時，我們增加一個互斥變量參數是必要的，這是為了避免線程間的競爭和饑餓情況。但是當條件等待返回時候，需要注意的是一定不要遺漏對互斥變量進行解鎖。

?

Linux 平臺上的 pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex) 函數返回時，互斥鎖 mutex 將處于鎖定狀態。因此之后如果需要對臨界區數據進行重新訪問，則沒有必要對 mutex 就行重新加鎖。但是，隨之而來的問題是，每次條件等待以后需要加入一步手動的解鎖操作。正如前文中乘客等待出租車的 Linux 代碼如清單 6 所示：

?

清單 6. 條件變量返回后的解鎖實例

?

void * traveler_arrive(void * name) { ????cout<< ” Traveler: ” <<(char *)name<< ” needs a taxi now! ” <<endl; ????pthread_mutex_lock(&taxiMutex); ????pthread_cond_wait (&taxiCond, &taxtMutex); ????pthread_mutex_unlock (&taxtMutex); ????cout<< ” Traveler: ” << (char *)name << ” now got a taxi! ” <<endl; ????pthread_exit( (void *)0 ); ?}

?

這一點對于熟悉 Windows 平臺多線程開發的開發者來說尤為重要。 Windows 上的 SignalObjectAndWait() 函數是常與 Linux 平臺上的 pthread_cond_wait() 函數被看作是跨平臺編程時的一對等價函數。但是需要注意的是，兩個函數退出時的狀態是不一樣的。在 Windows 平臺上，SignalObjectAndWait(HANDLE a, HANDLE b, …… ) 方法在調用結束返回時的狀態是 a 和 b 都是置位（signaled）狀態，在普遍的使用方法中，a 經常是一個 Mutex 變量，在這種情況下，當返回時，Mutex a 處于解鎖狀態（signaled），Event b 處于置位狀態（signaled）, 因此，對于 Mutex a 而言，我們不需要考慮解鎖的問題。而且，在 SignalObjectAndWait() 之后，如果需要對臨界區數據進行重新訪問，都需要調用 WaitForSingleObject() 重新加鎖。這一點剛好與 Linux 下的 pthread_cond_wait() 完全相反。

?

Linux 對于 Windows 的這一點額外解鎖的操作區別很重要，一定得牢記。否則從 Windows 移植到 Linux 上的條件等待操作一旦忘了結束后的解鎖操作，程序將肯定會發生死鎖。

?

等待的絕對時間問題

?

超時是多線程編程中一個常見的概念。例如，當你在 Linux 平臺下使用 pthread_cond_timedwait() 時就需要指定超時這個參數，以便這個 API 的調用者最多只被阻塞指定的時間間隔。但是如果你是第一次使用這個 API 時，首先你需要了解的就是這個 API 當中超時參數的特殊性（就如本節標題所提示的那樣）。我們首先來看一下這個 API 的定義。 pthread_cond_timedwait() 定義請看清單 7 。

?

清單 7. pthread_cond_timedwait() 函數定義

?

int pthread_cond_timedwait(pthread_cond_t *restrict cond, ??????????????pthread_mutex_t *restrict mutex, ??????????????const struct timespec *restrict abstime);

?

參數 abstime 在這里用來表示和超時時間相關的一個參數，但是需要注意的是它所表示的是一個絕對時間，而不是一個時間間隔數值，只有當系統的當前時間達到或者超過 abstime 所表示的時間時，才會觸發超時事件。這對于擁有 Windows 平臺線程開發經驗的人來說可能尤為困惑。因為 Windows 平臺下所有的 API 等待參數（如 SignalObjectAndWait，等）都是相對時間，

?

假設我們指定相對的超時時間參數如 dwMilliseconds （單位毫秒）來調用和超時相關的函數，這樣就需要將 dwMilliseconds 轉化為 Linux 下的絕對時間參數 abstime 使用。常用的轉換方法如清單 8 所示：

?

清單 8. 相對時間到絕對時間轉換實例

?

/* get the current time */ ????struct timeval now; ????gettimeofday(&now, NULL); ????? ????/* add the offset to get timeout value */ ????abstime ->tv_nsec = now.tv_usec * 1000 + (dwMilliseconds % 1000) * 1000000; ????abstime ->tv_sec = now.tv_sec + dwMilliseconds / 1000;

?

Linux 的絕對時間看似簡單明了，卻是開發中一個非常隱晦的陷阱。而且一旦你忘了時間轉換，可以想象，等待你的錯誤將是多么的令人頭疼：如果忘了把相對時間轉換成絕對時間，相當于你告訴系統你所等待的超時時間是過去式的 1970 年 1 月 1 號某個時間段，于是操作系統毫不猶豫馬上送給你一個 timeout 的返回值，然后你會舉著拳頭抱怨為什么另外一個同步線程耗時居然如此之久，并一頭扎進尋找耗時原因的深淵里。

?

正確處理 Linux 平臺下的線程結束問題

?

在 Linux 平臺下，當處理線程結束時需要注意的一個問題就是如何讓一個線程善始善終，讓其所占資源得到正確釋放。在 Linux 平臺默認情況下，雖然各個線程之間是相互獨立的，一個線程的終止不會去通知或影響其他的線程。但是已經終止的線程的資源并不會隨著線程的終止而得到釋放，我們需要調用 pthread_join() 來獲得另一個線程的終止狀態并且釋放該線程所占的資源。 Pthread_join() 函數的定義如清單 9 。

?

清單 9. pthread_join 函數定義

?

int pthread_join(pthread_t th, void **thread_return);

?

調用該函數的線程將掛起，等待 th 所表示的線程的結束。 thread_return 是指向線程 th 返回值的指針。需要注意的是 th 所表示的線程必須是 joinable 的，即處于非 detached（游離）狀態；并且只可以有唯一的一個線程對 th 調用 pthread_join() 。如果 th 處于 detached 狀態，那么對 th 的 pthread_join() 調用將返回錯誤。

?

如果你壓根兒不關心一個線程的結束狀態，那么也可以將一個線程設置為 detached 狀態，從而來讓操作系統在該線程結束時來回收它所占的資源。將一個線程設置為 detached 狀態可以通過兩種方式來實現。一種是調用 pthread_detach() 函數，可以將線程 th 設置為 detached 狀態。其申明如清單 10 。

?

清單 10. pthread_detach 函數定義

?

int pthread_detach(pthread_t th);

?

另一種方法是在創建線程時就將它設置為 detached 狀態，首先初始化一個線程屬性變量，然后將其設置為 detached 狀態，最后將它作為參數傳入線程創建函數 pthread_create()，這樣所創建出來的線程就直接處于 detached 狀態。方法如清單 11 。

?

清單 11. 創建 detach 線程代碼實例

?

………………………………… .. ????pthread_t?????? tid; ????pthread_attr_t? attr; ????pthread_attr_init(&attr); ????pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED); ????pthread_create(&tid, &attr, THREAD_FUNCTION, arg);

?

總之為了在使用 Pthread 時避免線程的資源在線程結束時不能得到正確釋放，從而避免產生潛在的內存泄漏問題，在對待線程結束時，要確保該線程處于 detached 狀態，否著就需要調用 pthread_join() 函數來對其進行資源回收。

?

總結與補充

?

本文以上部分詳細介紹了 Linux 的多線程編程的 5 條高效開發經驗。另外你也可以考慮嘗試其他一些開源類庫來進行線程開發。

?

1. Boost 庫

?

Boost 庫來自于由 C++ 標準委員會類庫工作組成員發起，致力于為 C++ 開發新的類庫的 Boost 組織。雖然該庫本身并不是針對多線程而產生，但是發展至今，其已提供了比較全面的多線程編程的 API 支持。 Boost 庫對于多線程支持的 API 風格上更類似于 Linux 的 Pthread 庫，差別在于其將線程，互斥鎖，條件等線程開發概念都封裝成了 C++ 類，以方便開發調用。 Boost 庫目前對跨平臺支持的很不錯，不僅支持 Windows 和 Linux ，還支持各種商用的 Unix 版本。如果開發者想使用高穩定性的統一線程編程接口減輕跨平臺開發的難度， Boost 庫將是首選。

?

2. ACE

?

ACE 全稱是 ADAPTIVE Communication Environment，它是一個免費的，開源的，面向對象的工具框架，用以開發并發訪問的軟件。由于 ACE 最初是面向網絡服務端的編程開發，因此對于線程開發的工具庫它也能提供很全面的支持。其支持的平臺也很全面，包括 Windows，Linux 和各種版本 Unix 。 ACE 的唯一問題是如果僅僅是用于線程編程，其似乎顯得有些過于重量級。而且其較復雜的配置也讓其部署對初學者而言并非易事。

?

相關主題

?

• IBM Developerworks 以下系列文章系列詳細介紹了如何對線程程序從 Windows 到 Linux 上進行移植。
• 文章《Strategies for Implementing POSIX Condition Variables on Win32》很全面的介紹了如何在 Windows 上實現 POSIX condition。
• 參閱 Boost 庫的官方網站
• 參閱 ACE 庫的官方網站

?

?

?

?

?

Linux 線程實現機制分析

?

?

一.基礎知識：線程和進程

?

按照教科書上的定義，進程是資源管理的最小單位，線程是程序執行的最小單位。在操作系統設計上，從進程演化出線程，最主要的目的就是更好的支持SMP以及減小（進程/線程）上下文切換開銷。

?

無論按照怎樣的分法，一個進程至少需要一個線程作為它的指令執行體，進程管理著資源（比如cpu、內存、文件等等），而將線程分配到某個cpu上執行。一個進程當然可以擁有多個線程，此時，如果進程運行在SMP機器上，它就可以同時使用多個cpu來執行各個線程，達到最大程度的并行，以提高效率；同時，即使是在單cpu的機器上，采用多線程模型來設計程序，正如當年采用多進程模型代替單進程模型一樣，使設計更簡潔、功能更完備，程序的執行效率也更高，例如采用多個線程響應多個輸入，而此時多線程模型所實現的功能實際上也可以用多進程模型來實現，而與后者相比，線程的上下文切換開銷就比進程要小多了，從語義上來說，同時響應多個輸入這樣的功能，實際上就是共享了除cpu以外的所有資源的。

?

針對線程模型的兩大意義，分別開發出了核心級線程和用戶級線程兩種線程模型，分類的標準主要是線程的調度者在核內還是在核外。前者更利于并發使用多處理器的資源，而后者則更多考慮的是上下文切換開銷。在目前的商用系統中，通常都將兩者結合起來使用，既提供核心線程以滿足smp系統的需要，也支持用線程庫的方式在用戶態實現另一套線程機制，此時一個核心線程同時成為多個用戶態線程的調度者。正如很多技術一樣，"混合"通常都能帶來更高的效率，但同時也帶來更大的實現難度，出于"簡單"的設計思路，Linux從一開始就沒有實現混合模型的計劃，但它在實現上采用了另一種思路的"混合"。

?

在線程機制的具體實現上，可以在操作系統內核上實現線程，也可以在核外實現，后者顯然要求核內至少實現了進程，而前者則一般要求在核內同時也支持進程。核心級線程模型顯然要求前者的支持，而用戶級線程模型則不一定基于后者實現。這種差異，正如前所述，是兩種分類方式的標準不同帶來的。

?

當核內既支持進程也支持線程時，就可以實現線程-進程的"多對多"模型，即一個進程的某個線程由核內調度，而同時它也可以作為用戶級線程池的調度者，選擇合適的用戶級線程在其空間中運行。這就是前面提到的"混合"線程模型，既可滿足多處理機系統的需要，也可以最大限度的減小調度開銷。絕大多數商業操作系統（如Digital Unix、Solaris、Irix）都采用的這種能夠完全實現POSIX1003.1c標準的線程模型。在核外實現的線程又可以分為"一對一"、"多對一"兩種模型，前者用一個核心進程（也許是輕量進程）對應一個線程，將線程調度等同于進程調度，交給核心完成，而后者則完全在核外實現多線程，調度也在用戶態完成。后者就是前面提到的單純的用戶級線程模型的實現方式，顯然，這種核外的線程調度器實際上只需要完成線程運行棧的切換，調度開銷非常小，但同時因為核心信號（無論是同步的還是異步的）都是以進程為單位的，因而無法定位到線程，所以這種實現方式不能用于多處理器系統，而這個需求正變得越來越大，因此，在現實中，純用戶級線程的實現，除算法研究目的以外，幾乎已經消失了。

?

Linux內核只提供了輕量進程的支持，限制了更高效的線程模型的實現，但Linux著重優化了進程的調度開銷，一定程度上也彌補了這一缺陷。目前最流行的線程機制LinuxThreads所采用的就是線程-進程"一對一"模型，調度交給核心，而在用戶級實現一個包括信號處理在內的線程管理機制。Linux-LinuxThreads的運行機制正是本文的描述重點。

?

二.Linux 2.4內核中的輕量進程實現

?

最初的進程定義都包含程序、資源及其執行三部分，其中程序通常指代碼，資源在操作系統層面上通常包括內存資源、IO資源、信號處理等部分，而程序的執行通常理解為執行上下文，包括對cpu的占用，后來發展為線程。在線程概念出現以前，為了減小進程切換的開銷，操作系統設計者逐漸修正進程的概念，逐漸允許將進程所占有的資源從其主體剝離出來，允許某些進程共享一部分資源，例如文件、信號，數據內存，甚至代碼，這就發展出輕量進程的概念。Linux內核在2.0.x版本就已經實現了輕量進程，應用程序可以通過一個統一的clone()系統調用接口，用不同的參數指定創建輕量進程還是普通進程。在內核中，clone()調用經過參數傳遞和解釋后會調用do_fork()，這個核內函數同時也是fork()、vfork()系統調用的最終實現：

?

<linux-2.4.20/kernel/fork.c> int do_fork(unsigned long clone_flags, unsigned long stack_start, struct pt_regs *regs, unsigned long stack_size)

?

其中的clone_flags取自以下宏的"或"值：

?

<linux-2.4.20/include/linux/sched.h> #define CSIGNAL????? 0x000000ff? /* signal mask to be sent at exit */ #define CLONE_VM??? 0x00000100 /* set if VM shared between processes */ #define CLONE_FS??????? 0x00000200? /* set if fs info shared between processes */ #define CLONE_FILES???? 0x00000400? /* set if open files shared between processes */ #define CLONE_SIGHAND? 0x00000800 /* set if signal handlers and blocked signals shared */ #define CLONE_PID??? 0x00001000? /* set if pid shared */ #define CLONE_PTRACE? 0x00002000? /* set if we want to let tracing continue on the child too */ #define CLONE_VFORK? 0x00004000? /* set if the parent wants the child to wake it up on mm_release */ #define CLONE_PARENT? 0x00008000? /* set if we want to have the same parent as the cloner */ #define CLONE_THREAD? 0x00010000? /* Same thread group? */ #define CLONE_NEWNS? 0x00020000? /* New namespace group? */ #define CLONE_SIGNAL?? (CLONE_SIGHAND | CLONE_THREAD)

?

在do_fork()中，不同的clone_flags將導致不同的行為，對于LinuxThreads，它使用（CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND）參數來調用clone()創建"線程"，表示共享內存、共享文件系統訪問計數、共享文件描述符表，以及共享信號處理方式。本節就針對這幾個參數，看看Linux內核是如何實現這些資源的共享的。

?

1.CLONE_VM

?

do_fork()需要調用copy_mm()來設置task_struct中的mm和active_mm項，這兩個mm_struct數據與進程所關聯的內存空間相對應。如果do_fork()時指定了CLONE_VM開關，copy_mm()將把新的task_struct中的mm和active_mm設置成與current的相同，同時提高該mm_struct的使用者數目（mm_struct::mm_users）。也就是說，輕量級進程與父進程共享內存地址空間，由下圖示意可以看出mm_struct在進程中的地位：

?

?

2.CLONE_FS

?

task_struct中利用fs（struct fs_struct *）記錄了進程所在文件系統的根目錄和當前目錄信息，do_fork()時調用copy_fs()復制了這個結構；而對于輕量級進程則僅增加fs->count計數，與父進程共享相同的fs_struct。也就是說，輕量級進程沒有獨立的文件系統相關的信息，進程中任何一個線程改變當前目錄、根目錄等信息都將直接影響到其他線程。

?

3.CLONE_FILES

?

一個進程可能打開了一些文件，在進程結構task_struct中利用files（struct files_struct *）來保存進程打開的文件結構（struct file）信息，do_fork()中調用了copy_files()來處理這個進程屬性；輕量級進程與父進程是共享該結構的，copy_files()時僅增加files->count計數。這一共享使得任何線程都能訪問進程所維護的打開文件，對它們的操作會直接反映到進程中的其他線程。

?

4.CLONE_SIGHAND

?

每一個Linux進程都可以自行定義對信號的處理方式，在task_struct中的sig（struct signal_struct）中使用一個struct k_sigaction結構的數組來保存這個配置信息，do_fork()中的copy_sighand()負責復制該信息；輕量級進程不進行復制，而僅僅增加signal_struct::count計數，與父進程共享該結構。也就是說，子進程與父進程的信號處理方式完全相同，而且可以相互更改。

?

do_fork()中所做的工作很多，在此不詳細描述。對于SMP系統，所有的進程fork出來后，都被分配到與父進程相同的cpu上，一直到該進程被調度時才會進行cpu選擇。

?

盡管Linux支持輕量級進程，但并不能說它就支持核心級線程，因為Linux的"線程"和"進程"實際上處于一個調度層次，共享一個進程標識符空間，這種限制使得不可能在Linux上實現完全意義上的POSIX線程機制，因此眾多的Linux線程庫實現嘗試都只能盡可能實現POSIX的絕大部分語義，并在功能上盡可能逼近。

?

三.LinuxThread的線程機制

?

LinuxThreads是目前Linux平臺上使用最為廣泛的線程庫，由Xavier Leroy (Xavier.Leroy@inria.fr)負責開發完成，并已綁定在GLIBC中發行。它所實現的就是基于核心輕量級進程的"一對一"線程模型，一個線程實體對應一個核心輕量級進程，而線程之間的管理在核外函數庫中實現。

?

1.線程描述數據結構及實現限制

?

LinuxThreads定義了一個struct _pthread_descr_struct數據結構來描述線程，并使用全局數組變量__pthread_handles來描述和引用進程所轄線程。在__pthread_handles中的前兩項，LinuxThreads定義了兩個全局的系統線程：__pthread_initial_thread和__pthread_manager_thread，并用__pthread_main_thread表征__pthread_manager_thread的父線程（初始為__pthread_initial_thread）。

?

struct _pthread_descr_struct是一個雙環鏈表結構，__pthread_manager_thread所在的鏈表僅包括它一個元素，實際上，__pthread_manager_thread是一個特殊線程，LinuxThreads僅使用了其中的errno、p_pid、p_priority等三個域。而__pthread_main_thread所在的鏈則將進程中所有用戶線程串在了一起。經過一系列pthread_create()之后形成的__pthread_handles數組將如下圖所示：

?

?

新創建的線程將首先在__pthread_handles數組中占據一項，然后通過數據結構中的鏈指針連入以__pthread_main_thread為首指針的鏈表中。這個鏈表的使用在介紹線程的創建和釋放的時候將提到。

?

LinuxThreads遵循POSIX1003.1c標準，其中對線程庫的實現進行了一些范圍限制，比如進程最大線程數，線程私有數據區大小等等。在LinuxThreads的實現中，基本遵循這些限制，但也進行了一定的改動，改動的趨勢是放松或者說擴大這些限制，使編程更加方便。這些限定宏主要集中在sysdeps/unix/sysv/linux/bits/local_lim.h（不同平臺使用的文件位置不同）中，包括如下幾個：

?

每進程的私有數據key數，POSIX定義_POSIX_THREAD_KEYS_MAX為128，LinuxThreads使用PTHREAD_KEYS_MAX，1024；私有數據釋放時允許執行的操作數，LinuxThreads與POSIX一致，定義PTHREAD_DESTRUCTOR_ITERATIONS為4；每進程的線程數，POSIX定義為64，LinuxThreads增大到1024（PTHREAD_THREADS_MAX）；線程運行棧最小空間大小，POSIX未指定，LinuxThreads使用PTHREAD_STACK_MIN，16384（字節）。

?

2.管理線程

?

"一對一"模型的好處之一是線程的調度由核心完成了，而其他諸如線程取消、線程間的同步等工作，都是在核外線程庫中完成的。在LinuxThreads中，專門為每一個進程構造了一個管理線程，負責處理線程相關的管理工作。當進程第一次調用pthread_create()創建一個線程的時候就會創建（__clone()）并啟動管理線程。

?

在一個進程空間內，管理線程與其他線程之間通過一對"管理管道（manager_pipe[2]）"來通訊，該管道在創建管理線程之前創建，在成功啟動了管理線程之后，管理管道的讀端和寫端分別賦給兩個全局變量__pthread_manager_reader和__pthread_manager_request，之后，每個用戶線程都通過__pthread_manager_request向管理線程發請求，但管理線程本身并沒有直接使用__pthread_manager_reader，管道的讀端（manager_pipe[0]）是作為__clone()的參數之一傳給管理線程的，管理線程的工作主要就是監聽管道讀端，并對從中取出的請求作出反應。

?

創建管理線程的流程如下所示：
（全局變量pthread_manager_request初值為-1）

?

?

初始化結束后，在__pthread_manager_thread中記錄了輕量級進程號以及核外分配和管理的線程id，2*PTHREAD_THREADS_MAX+1這個數值不會與任何常規用戶線程id沖突。管理線程作為pthread_create()的調用者線程的子線程運行，而pthread_create()所創建的那個用戶線程則是由管理線程來調用clone()創建，因此實際上是管理線程的子線程。（此處子線程的概念應該當作子進程來理解。）

?

__pthread_manager()就是管理線程的主循環所在，在進行一系列初始化工作后，進入while(1)循環。在循環中，線程以2秒為timeout查詢（__poll()）管理管道的讀端。在處理請求前，檢查其父線程（也就是創建manager的主線程）是否已退出，如果已退出就退出整個進程。如果有退出的子線程需要清理，則調用pthread_reap_children()清理。

?

然后才是讀取管道中的請求，根據請求類型執行相應操作（switch-case）。具體的請求處理，源碼中比較清楚，這里就不贅述了。

?

3.線程棧

?

在LinuxThreads中，管理線程的棧和用戶線程的棧是分離的，管理線程在進程堆中通過malloc()分配一個THREAD_MANAGER_STACK_SIZE字節的區域作為自己的運行棧。

?

用戶線程的棧分配辦法隨著體系結構的不同而不同，主要根據兩個宏定義來區分，一個是NEED_SEPARATE_REGISTER_STACK，這個屬性僅在IA64平臺上使用；另一個是FLOATING_STACK宏，在i386等少數平臺上使用，此時用戶線程棧由系統決定具體位置并提供保護。與此同時，用戶還可以通過線程屬性結構來指定使用用戶自定義的棧。因篇幅所限，這里只能分析i386平臺所使用的兩種棧組織方式：FLOATING_STACK方式和用戶自定義方式。

?

在FLOATING_STACK方式下，LinuxThreads利用mmap()從內核空間中分配8MB空間（i386系統缺省的最大?？臻g大小，如果有運行限制（rlimit），則按照運行限制設置），使用mprotect()設置其中第一頁為非訪問區。該8M空間的功能分配如下圖：

?

?

低地址被保護的頁面用來監測棧溢出。

?

對于用戶指定的棧，在按照指針對界后，設置線程棧頂，并計算出棧底，不做保護，正確性由用戶自己保證。

?

不論哪種組織方式，線程描述結構總是位于棧頂緊鄰堆棧的位置。

?

4.線程id和進程id

?

每個LinuxThreads線程都同時具有線程id和進程id，其中進程id就是內核所維護的進程號，而線程id則由LinuxThreads分配和維護。

?

__pthread_initial_thread的線程id為PTHREAD_THREADS_MAX，__pthread_manager_thread的是2*PTHREAD_THREADS_MAX+1，第一個用戶線程的線程id為PTHREAD_THREADS_MAX+2，此后第n個用戶線程的線程id遵循以下公式：

tid=n*PTHREAD_THREADS_MAX+n+1

?

?

這種分配方式保證了進程中所有的線程（包括已經退出）都不會有相同的線程id，而線程id的類型pthread_t定義為無符號長整型（unsigned long int），也保證了有理由的運行時間內線程id不會重復。

?

從線程id查找線程數據結構是在pthread_handle()函數中完成的，實際上只是將線程號按PTHREAD_THREADS_MAX取模，得到的就是該線程在__pthread_handles中的索引。

?

5.線程的創建

?

在pthread_create()向管理線程發送REQ_CREATE請求之后，管理線程即調用pthread_handle_create()創建新線程。分配棧、設置thread屬性后，以pthread_start_thread()為函數入口調用__clone()創建并啟動新線程。pthread_start_thread()讀取自身的進程id號存入線程描述結構中，并根據其中記錄的調度方法配置調度。一切準備就緒后，再調用真正的線程執行函數，并在此函數返回后調用pthread_exit()清理現場。

?

6.LinuxThreads的不足

?

由于Linux內核的限制以及實現難度等等原因，LinuxThreads并不是完全POSIX兼容的，在它的發行README中有說明。

?

1)進程id問題

?

這個不足是最關鍵的不足，引起的原因牽涉到LinuxThreads的"一對一"模型。

?

Linux內核并不支持真正意義上的線程，LinuxThreads是用與普通進程具有同樣內核調度視圖的輕量級進程來實現線程支持的。這些輕量級進程擁有獨立的進程id，在進程調度、信號處理、IO等方面享有與普通進程一樣的能力。在源碼閱讀者看來，就是Linux內核的clone()沒有實現對CLONE_PID參數的支持。

?

在內核do_fork()中對CLONE_PID的處理是這樣的：

?

? if (clone_flags & CLONE_PID) { ????????if (current->pid) ????????????????goto fork_out; }

?

這段代碼表明，目前的Linux內核僅在pid為0的時候認可CLONE_PID參數，實際上，僅在SMP初始化，手工創建進程的時候才會使用CLONE_PID參數。

?

按照POSIX定義，同一進程的所有線程應該共享一個進程id和父進程id，這在目前的"一對一"模型下是無法實現的。

?

2)信號處理問題

?

由于異步信號是內核以進程為單位分發的，而LinuxThreads的每個線程對內核來說都是一個進程，且沒有實現"線程組"，因此，某些語義不符合POSIX標準，比如沒有實現向進程中所有線程發送信號，README對此作了說明。

?

如果核心不提供實時信號，LinuxThreads將使用SIGUSR1和SIGUSR2作為內部使用的restart和cancel信號，這樣應用程序就不能使用這兩個原本為用戶保留的信號了。在Linux kernel 2.1.60以后的版本都支持擴展的實時信號（從_SIGRTMIN到_SIGRTMAX），因此不存在這個問題。

?

某些信號的缺省動作難以在現行體系上實現，比如SIGSTOP和SIGCONT，LinuxThreads只能將一個線程掛起，而無法掛起整個進程。

?

3)線程總數問題

?

LinuxThreads將每個進程的線程最大數目定義為1024，但實際上這個數值還受到整個系統的總進程數限制，這又是由于線程其實是核心進程。

?

在kernel 2.4.x中，采用一套全新的總進程數計算方法，使得總進程數基本上僅受限于物理內存的大小，計算公式在kernel/fork.c的fork_init()函數中：

?

max_threads = mempages / (THREAD_SIZE/PAGE_SIZE) / 8

?

在i386上，THREAD_SIZE=2*PAGE_SIZE，PAGE_SIZE=2^12（4KB），mempages=物理內存大小/PAGE_SIZE，對于256M的內存的機器，mempages=256*2^20/2^12=256*2^8，此時最大線程數為4096。

?

但為了保證每個用戶（除了root）的進程總數不至于占用一半以上物理內存，fork_init()中繼續指定：

?

init_task.rlim[RLIMIT_NPROC].rlim_cur = max_threads/2; init_task.rlim[RLIMIT_NPROC].rlim_max = max_threads/2;

?

這些進程數目的檢查都在do_fork()中進行，因此，對于LinuxThreads來說，線程總數同時受這三個因素的限制。

?

4)管理線程問題

?

管理線程容易成為瓶頸，這是這種結構的通病；同時，管理線程又負責用戶線程的清理工作，因此，盡管管理線程已經屏蔽了大部分的信號，但一旦管理線程死亡，用戶線程就不得不手工清理了，而且用戶線程并不知道管理線程的狀態，之后的線程創建等請求將無人處理。

?

5)同步問題

?

LinuxThreads中的線程同步很大程度上是建立在信號基礎上的，這種通過內核復雜的信號處理機制的同步方式，效率一直是個問題。

?

6）其他POSIX兼容性問題

?

Linux中很多系統調用，按照語義都是與進程相關的，比如nice、setuid、setrlimit等，在目前的LinuxThreads中，這些調用都僅僅影響調用者線程。

?

7）實時性問題

?

線程的引入有一定的實時性考慮，但LinuxThreads暫時不支持，比如調度選項，目前還沒有實現。不僅LinuxThreads如此，標準的Linux在實時性上考慮都很少。

?

四.其他的線程實現機制

?

LinuxThreads的問題，特別是兼容性上的問題，嚴重阻礙了Linux上的跨平臺應用（如Apache）采用多線程設計，從而使得Linux上的線程應用一直保持在比較低的水平。在Linux社區中，已經有很多人在為改進線程性能而努力，其中既包括用戶級線程庫，也包括核心級和用戶級配合改進的線程庫。目前最為人看好的有兩個項目，一個是RedHat公司牽頭研發的NPTL（Native Posix Thread Library），另一個則是IBM投資開發的NGPT（Next Generation Posix Threading），二者都是圍繞完全兼容POSIX 1003.1c，同時在核內和核外做工作以而實現多對多線程模型。這兩種模型都在一定程度上彌補了LinuxThreads的缺點，且都是重起爐灶全新設計的。

?

1.NPTL

?

NPTL的設計目標歸納可歸納為以下幾點：

?

• POSIX兼容性
• SMP結構的利用
• 低啟動開銷
• 低鏈接開銷（即不使用線程的程序不應當受線程庫的影響）
• 與LinuxThreads應用的二進制兼容性
• 軟硬件的可擴展能力
• 多體系結構支持
• NUMA支持
• 與C++集成

?

在技術實現上，NPTL仍然采用1:1的線程模型，并配合glibc和最新的Linux Kernel2.5.x開發版在信號處理、線程同步、存儲管理等多方面進行了優化。和LinuxThreads不同，NPTL沒有使用管理線程，核心線程的管理直接放在核內進行，這也帶了性能的優化。

?

主要是因為核心的問題，NPTL仍然不是100%POSIX兼容的，但就性能而言相對LinuxThreads已經有很大程度上的改進了。

?

2.NGPT

?

IBM的開放源碼項目NGPT在2003年1月10日推出了穩定的2.2.0版，但相關的文檔工作還差很多。就目前所知，NGPT是基于GNU Pth（GNU Portable Threads）項目而實現的M:N模型，而GNU Pth是一個經典的用戶級線程庫實現。

?

按照2003年3月NGPT官方網站上的通知，NGPT考慮到NPTL日益廣泛地為人所接受，為避免不同的線程庫版本引起的混亂，今后將不再進行進一步開發，而今進行支持性的維護工作。也就是說，NGPT已經放棄與NPTL競爭下一代Linux POSIX線程庫標準。

?

3.其他高效線程機制

?

此處不能不提到Scheduler Activations。這個1991年在ACM上發表的多線程內核結構影響了很多多線程內核的設計，其中包括Mach3.0、NetBSD和商業版本Digital Unix（現在叫Compaq True64 Unix）。它的實質是在使用用戶級線程調度的同時，盡可能地減少用戶級對核心的系統調用請求，而后者往往是運行開銷的重要來源。采用這種結構的線程機制，實際上是結合了用戶級線程的靈活高效和核心級線程的實用性，因此，包括Linux、FreeBSD在內的多個開放源碼操作系統設計社區都在進行相關研究，力圖在本系統中實現Scheduler Activations。

?

相關主題

?

• • [Linus Torvalds，2002] Linux內核源碼v2.4.20
  • [GNU，2002] Glibc源碼v2.2.2（內含LinuxThreads v0.9）
  • [Thomas E. Terrill，1997] An Introduction to Threads Using The LinuxThreads Interface
  • [Ulrich Drepper，Ingo Molnar，2003] The Native POSIX Thread Library for Linux
  • http://www.ibm.com/developerworks/oss/pthreads/，NGPT官方網站
  • [Ralf S. Engelschall，2000] Portable Multithreading
  • [Thomas E. Anderson, Brian N. Bershad, Edward D. Lazowska, Henry M. Levy，1992] Scheduler Activations: Effective Kernel Support for the User-Level Management of Parallelism
  • [pcjockey@21cn.com] Linux線程初探

?

轉載于:https://www.cnblogs.com/alantu2018/p/8477038.html

總結

以上是生活随笔為你收集整理的线程模型、pthread 系列函数 和 简单多线程服务器端程序的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。