线程模型、pthread 系列函数 和 简单多线程服务器端程序
一、線程有3種模型，分別是N:1用戶線程模型，1:1核心線程模型和N:M混合線程模型，posix thread屬于1:1模型。
（一）、N:1用戶線程模型
“線程實(shí)現(xiàn)”建立在“進(jìn)程控制”機(jī)制之上，由用戶空間的程序庫(kù)來管理。OS內(nèi)核完全不知道線程信息。這些線程稱為用戶空間線程。這些線程都工作在“進(jìn)
程競(jìng)爭(zhēng)范圍”（process contention scope）：各個(gè)線程在同一進(jìn)程競(jìng)爭(zhēng)“被調(diào)度的CPU時(shí)間”（但不直接和其他進(jìn)程中的線程競(jìng)爭(zhēng)）。
在N:1線程模型中，內(nèi)核不干涉線程的任何生命活動(dòng)，也不干涉同一進(jìn)程中的線程環(huán)境切換。
在N:1線程模型中，一個(gè)進(jìn)程中的多個(gè)線程只能調(diào)度到一個(gè)CPU，這種約束限制了可用的并行總量。
第二個(gè)缺點(diǎn)是如果某個(gè)線程執(zhí)行了一個(gè)“阻塞式”操作（如read），那么，進(jìn)程中的所有線程都會(huì)阻塞，直至那個(gè)操作結(jié)束。為此，一些線程的實(shí)現(xiàn)是為
這些阻塞式函數(shù)提供包裝器，用非阻塞版本替換這些系統(tǒng)調(diào)用，以消除這種限制。
（二）、1:1核心線程模型?pthread線程庫(kù)--NPTL(Native POSIX Threading Library)
在1:1核心線程模型中，應(yīng)用程序創(chuàng)建的每一個(gè)線程（也有書稱為L(zhǎng)WP）都由一個(gè)核心線程直接管理。OS內(nèi)核將每一個(gè)核心線程都調(diào)到系統(tǒng)CPU上，
因此，所有線程都工作在“系統(tǒng)競(jìng)爭(zhēng)范圍”（system contention scope）：線程直接和“系統(tǒng)范圍”內(nèi)的其他線程競(jìng)爭(zhēng)。
這種線程的創(chuàng)建與調(diào)度由內(nèi)核完成，因?yàn)檫@種線程的系統(tǒng)開銷比較大（但一般來說，比進(jìn)程開銷小）
（三）、N:M混合線程模型 ?NGPT(Next Generation POSIX Threads)
N:M混合線程模型提供了兩級(jí)控制，將用戶線程映射為系統(tǒng)的可調(diào)度體以實(shí)現(xiàn)并行，這個(gè)可調(diào)度體稱為輕量級(jí)進(jìn)程（LWP:light weight process），LWP 再一一映射到核心線程。如下圖所示。OS內(nèi)核將每一個(gè)核心線程都調(diào)到系統(tǒng)CPU上，因此，所有線程都工作在“系統(tǒng)競(jìng)爭(zhēng)范圍”。據(jù)說一些類UNIX系統(tǒng)(如Solaris)已經(jīng)實(shí)現(xiàn)了比較成熟的M:N線程模型, 其性能比起linux的線程還是有著一定的優(yōu)勢(shì)，但不能利用SMP結(jié)構(gòu)。
按照2003年3月NGPT官方網(wǎng)站上的通知，NGPT考慮到NPTL日益廣泛地為人所接受，為避免不同的線程庫(kù)版本引起的混亂，今后將不再進(jìn)行進(jìn)一步開發(fā)，而今進(jìn)行支持性的維護(hù)工作。也就是說，NGPT已經(jīng)放棄與NPTL競(jìng)爭(zhēng)下一代Linux POSIX線程庫(kù)標(biāo)準(zhǔn)。
二、posix 線程概述
我們知道，進(jìn)程在各自獨(dú)立的地址空間中運(yùn)行，進(jìn)程之間共享數(shù)據(jù)需要用進(jìn)程間通信機(jī)制，有些情況需要在一個(gè)進(jìn)程中同時(shí)執(zhí)行多個(gè)控制流程，這時(shí)候
線程就派上了用場(chǎng)，比如實(shí)現(xiàn)一個(gè)圖形界面的下載軟件，一方面需要和用戶交互，等待和處理用戶的鼠標(biāo)鍵盤事件，另一方面又需要同時(shí)下載多個(gè)文
件，等待和處理從多個(gè)網(wǎng)絡(luò)主機(jī)發(fā)來的數(shù)據(jù)，這些任務(wù)都需要一個(gè)“等待-處理”的循環(huán)，可以用多線程實(shí)現(xiàn)，一個(gè)線程專門負(fù)責(zé)與用戶交互，另外幾個(gè)線
程每個(gè)線程負(fù)責(zé)和一個(gè)網(wǎng)絡(luò)主機(jī)通信。
以前我們講過，main函數(shù)和信號(hào)處理函數(shù)是同一個(gè)進(jìn)程地址空間中的多個(gè)控制流程，多線程也是如此，但是比信號(hào)處理函數(shù)更加靈活，信號(hào)處理函數(shù)的
控制流程只是在信號(hào)遞達(dá)時(shí)產(chǎn)生，在處理完信號(hào)之后就結(jié)束，而多線程的控制流程可以長(zhǎng)期并存，操作系統(tǒng)會(huì)在各線程之間調(diào)度和切換，就像在多個(gè)進(jìn)
程之間調(diào)度和切換一樣。由于同一進(jìn)程的多個(gè)線程共享同一地址空間，因此Text Segment、Data Segment都是共享的，如果定義一個(gè)函數(shù)，在各線程
中都可以調(diào)用，如果定義一個(gè)全局變量，在各線程中都可以訪問到，除此之外，各線程還共享以下進(jìn)程資源和環(huán)境：
文件描述符表
每種信號(hào)的處理方式（SIG_IGN、SIG_DFL或者自定義的信號(hào)處理函數(shù)）
當(dāng)前工作目錄
用戶id和組id
但有些資源是每個(gè)線程各有一份的：
線程id
上下文，包括各種寄存器的值、程序計(jì)數(shù)器和棧指針
棧空間
errno變量
信號(hào)屏蔽字
調(diào)度優(yōu)先級(jí)
我們將要學(xué)習(xí)的線程庫(kù)函數(shù)是由POSIX標(biāo)準(zhǔn)定義的，稱為POSIX thread或者pthread。在Linux上線程函數(shù)位于libpthread共享庫(kù)中，因此在編譯時(shí)要加上-lpthread選項(xiàng)。
當(dāng)線程停止/繼續(xù), 或者是收到一個(gè)致命信號(hào)時(shí), 內(nèi)核會(huì)將處理動(dòng)作施加到整個(gè)線程組中。
比如程序a.out運(yùn)行時(shí)，創(chuàng)建了一個(gè)線程。假設(shè)主線程的pid是10001、子線程是10002（它們的tgid都是10001）。這時(shí)如果你kill 10002，是可以把10001和10002這兩個(gè)線程一起殺死的，盡管執(zhí)行ps命令的時(shí)候根本看不到10002這個(gè)進(jìn)程。如果你不知道linux線程背后的故事，肯定會(huì)覺得遇到靈異事件了。
?
三、pthread 系列函數(shù)
（一）
功能：創(chuàng)建一個(gè)新的線程
原型 int pthread_create(pthread_t *thread, const pthread_attr_t *attr, void *(*start_routine)(void*), void *arg);
參數(shù)
thread:返回線程ID
attr:設(shè)置線程的屬性，attr為NULL表示使用默認(rèn)屬性
start_routine:是個(gè)函數(shù)地址，線程啟動(dòng)后要執(zhí)行的函數(shù)
arg:傳給線程啟動(dòng)函數(shù)的參數(shù)
返回值：成功返回0；失敗返回錯(cuò)誤碼
錯(cuò)誤檢查：
以前學(xué)過的系統(tǒng)函數(shù)都是成功返回0，失敗返回-1，而錯(cuò)誤號(hào)保存在全局變量errno中，而pthread庫(kù)的函數(shù)都是通過返回值返回錯(cuò)誤號(hào)，雖然每個(gè)線程也都有一個(gè)errno，但這是為了兼容其它函數(shù)接口而提供的，pthread庫(kù)本身并不使用它，通過返回值返回錯(cuò)誤碼更加清晰。由于pthread_create的錯(cuò)誤碼不保存在errno中，因此不能直接用perror(3)打印錯(cuò)誤信息，可以先用strerror(3)把錯(cuò)誤號(hào)轉(zhuǎn)換成錯(cuò)誤信息再打印。
（二）
功能：線程終止
原型 void pthread_exit(void *value_ptr);
參數(shù)
value_ptr：value_ptr不要指向一個(gè)局部變量，因?yàn)楫?dāng)其它線程得到這個(gè)返回指針時(shí)線程函數(shù)已經(jīng)退出了。
返回值：無返回值，跟進(jìn)程一樣，線程結(jié)束的時(shí)候無法返回到它的調(diào)用者（自身）
如果需要只終止某個(gè)線程而不終止整個(gè)進(jìn)程，可以有三種方法：
1、從線程函數(shù)return。這種方法對(duì)主線程不適用，從main函數(shù)return相當(dāng)于調(diào)用exit，而如果任意一個(gè)線程調(diào)用了exit或_exit，則整個(gè)進(jìn)程的所有線程都終止。
2、一個(gè)線程可以調(diào)用pthread_cancel 終止同一進(jìn)程中的另一個(gè)線程。
3、線程可以調(diào)用pthread_exit終止自己。
（三）
功能：等待線程結(jié)束
原型 int pthread_join(pthread_t thread, void **value_ptr);
參數(shù)
thread:線程ID
value_ptr:它指向一個(gè)指針，后者指向線程的返回值
返回值：成功返回0；失敗返回錯(cuò)誤碼
當(dāng)pthread_create 中的 start_routine返回時(shí)，這個(gè)線程就退出了，其它線程可以調(diào)用pthread_join得到start_routine的返回值，類似于父進(jìn)程調(diào)用wait(2)得到子進(jìn)程的退出狀態(tài)。
調(diào)用該函數(shù)的線程將掛起等待，直到id為thread的線程終止。thread線程以不同的方法終止，通過pthread_join得到的終止?fàn)顟B(tài)是不同的，總結(jié)如下：
1、如果thread線程通過return返回，value_ptr所指向的單元里存放的是thread線程函數(shù)的返回值。
2、如果thread線程被別的線程調(diào)用pthread_cancel異常終止掉，value_ptr所指向的單元里存放的是常數(shù)PTHREAD_CANCELED。
3、如果thread線程是自己調(diào)用pthread_exit終止的，value_ptr所指向的單元存放的是傳給pthread_exit的參數(shù)。
如果對(duì)thread線程的終止?fàn)顟B(tài)不感興趣，可以傳NULL給value_ptr參數(shù)。
（四）
功能：返回線程ID
原型 pthread_t pthread_self(void);
返回值：成功返回線程id
在Linux上，pthread_t類型是一個(gè)地址值，屬于同一進(jìn)程的多個(gè)線程調(diào)用getpid(2)可以得到相同的進(jìn)程號(hào)，而調(diào)用pthread_self(3)得到的線程號(hào)各不相同。線程id只在當(dāng)前進(jìn)程中保證是唯一的，在不同的系統(tǒng)中pthread_t這個(gè)類型有不同的實(shí)現(xiàn)，它可能是一個(gè)整數(shù)值，也可能是一個(gè)結(jié)構(gòu)體，也可能是一個(gè)地址，所以不能簡(jiǎn)單地當(dāng)成整數(shù)用printf打印。
（五）
功能：取消一個(gè)執(zhí)行中的線程
原型 int pthread_cancel(pthread_t thread);
參數(shù)
thread:線程ID
返回值：成功返回0；失敗返回錯(cuò)誤碼
一個(gè)新創(chuàng)建的線程默認(rèn)取消狀態(tài)（cancelability state）是可取消的，取消類型（?cancelability type）是同步的，即在某個(gè)可取消點(diǎn)（?cancellation point，即在執(zhí)行某些函數(shù)的時(shí)候）才會(huì)取消線程。具體可以man 一下。
相關(guān)函數(shù)?int pthread_setcancelstate(int state, int *oldstate); ?int pthread_setcanceltype(int type, int *oldtype); 為保證一個(gè)事務(wù)型處理邏輯的完整可以使用這兩個(gè)函數(shù)，如下舉例，主線程創(chuàng)建完線程睡眠一陣調(diào)用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; } |
就算我們?cè)谕瓿梢淮瓮暾壿嫼蟛涣⒓锤幕?PTHREAD_CANCEL_ENABLE，就算后續(xù)循環(huán)再次調(diào)用?PTHREAD_CANCEL_DISABLE 設(shè)置，其 "未決狀態(tài)" 依然會(huì)保留的。循環(huán)執(zhí)行i=0~8 后，i=9時(shí)在sleep可取消點(diǎn)線程被中斷。
（六）
功能：將一個(gè)線程分離
原型 int pthread_detach(pthread_t thread);
參數(shù)
thread:線程ID
返回值：成功返回0；失敗返回錯(cuò)誤碼
一般情況下，線程終止后，其終止?fàn)顟B(tài)一直保留到其它線程調(diào)用pthread_join獲取它的狀態(tài)為止（僵線程）。但是線程也可以被置為detach狀態(tài)，這樣的線程一旦終止就立刻回收它占用的所有資源，而不保留終止?fàn)顟B(tài)。不能對(duì)一個(gè)已經(jīng)處于detach狀態(tài)的線程調(diào)用pthread_join，這樣的調(diào)用將返回EINVAL。對(duì)一個(gè)尚未detach的線程調(diào)用pthread_join或pthread_detach都可以把該線程置為detach狀態(tài)，也就是說，不能對(duì)同一線程調(diào)用兩次pthread_join，或者如果已經(jīng)對(duì)一個(gè)線程調(diào)用了pthread_detach就不能再調(diào)用pthread_join了。
這個(gè)函數(shù)既可以在主線程中調(diào)用，也可以在thread_function里面調(diào)用。
在主線程中通過線程屬性也可以達(dá)到同樣的效果，如下：
?
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); |
下面寫個(gè)程序走一下這些函數(shù)：
?
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; } |
?
創(chuàng)建一個(gè)線程，主線程打印A，新線程打印B，主線程調(diào)用pthread_join 等待新線程退出，打印退出值。
simba@ubuntu:~/Documents/code/linux_programming/UNP/pthread$ ./pthread_create?
ABAABABABABABABABABABABABABAABABBABABABB
return msg=DEF
在新線程中也可調(diào)用pthread_exit 退出。
四、簡(jiǎn)單的多線程服務(wù)器端程序
在將socket 編程的時(shí)候曾經(jīng)使用fork 多進(jìn)程的方式來實(shí)現(xiàn)并發(fā)，現(xiàn)在嘗試使用多線程方式來實(shí)現(xiàn)：
?
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) { ????/*?主線程沒有調(diào)用pthread_join等待線程退出?*/ ????pthread_detach(pthread_self());?//剝離線程，避免產(chǎn)生僵線程 ????/*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問題，竟態(tài)問題 ????????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位系統(tǒng)時(shí)指針不是4個(gè)字節(jié)，不可移植 ????????????????{ ????????????????????fprintf(stderr,?"pthread_create:%s\n",?strerror(ret)); ????????????????????exit(EXIT_FAILURE); ????????????????} ????????*/ ????} |
?
程序邏輯并不復(fù)雜，一旦accept 返回一個(gè)已連接套接字，就創(chuàng)建一個(gè)新線程對(duì)其服務(wù)，在每個(gè)新線程thread_routine 中調(diào)用pthread_detach 剝離線程，我們的主線程不能調(diào)用pthread_join 等待這些新線程的退出，因?yàn)檫€要返回while 循環(huán)開頭去在accept 中阻塞監(jiān)聽。
如果使用pthread_create(&tid, NULL, thread_routine, (void*)&conn); 存在的問題是如果accept 再次返回一個(gè)已連接套接字，而此時(shí)thread_routine 函數(shù)還沒取走conn 時(shí)，可能會(huì)讀取到已經(jīng)被更改的conn 值。
如果使用 ?pthread_create(&tid, NULL, thread_routine, (void*)conn); 存在的問題是在64位系統(tǒng)中指針不是4個(gè)字節(jié)而是8個(gè)字節(jié)，即不可移植 性。
使用上述未被注釋的做法，每次返回一個(gè)conn，就malloc 一塊內(nèi)存存放起來，在thread_routine 函數(shù)中去讀取即可。
開多個(gè)客戶端，可以看到正常服務(wù)。
后記：其實(shí) pthread 系列函數(shù)也可以應(yīng)用于進(jìn)程間加鎖，怎么應(yīng)用到多進(jìn)程場(chǎng)合呢，被多個(gè)進(jìn)程共享呢？
很簡(jiǎn)單，首先需要設(shè)置互斥鎖的進(jìn)程間共享屬性：
?
?
C++ Code?| 1 2 3 4 | ? | int?pshared); pthread_mutexattr_t?mattr; pthread_mutexattr_init(&mattr); pthread_mutexattr_setpshared(&mattr,?PTHREAD_PROCESS_SHARED); |
其次，為了達(dá)到多進(jìn)程共享的需要，互斥鎖對(duì)象需要?jiǎng)?chuàng)建在共享內(nèi)存中。
最后，需要注意的是，并不是所有Linux系統(tǒng)都支持這個(gè)特性，程序里需要檢查是否定義了_POSIX_SHARED_MEMORY_OBJECTS宏，只有定義了才能用這種方式實(shí)現(xiàn)進(jìn)程間互斥鎖。
參考：
《linux c 編程一站式學(xué)習(xí)》
《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 的多線程編程的高效開發(fā)經(jīng)驗(yàn)
?
?
背景
?
Linux 平臺(tái)上的多線程程序開發(fā)相對(duì)應(yīng)其他平臺(tái)（比如 Windows）的多線程 API 有一些細(xì)微和隱晦的差別。不注意這些 Linux 上的一些開發(fā)陷阱，常常會(huì)導(dǎo)致程序問題不窮，死鎖不斷。本文中我們從 5 個(gè)方面總結(jié)出 Linux 多線程編程上的問題，并分別引出相關(guān)改善的開發(fā)經(jīng)驗(yàn)，用以避免這些的陷阱。我們希望這些經(jīng)驗(yàn)可以幫助讀者們能更好更快的熟悉 Linux 平臺(tái)的多線程編程。
?
我們假設(shè)讀者都已經(jīng)很熟悉 Linux 平臺(tái)上基本的線程編程的 Pthread 庫(kù) API 。其他的第三方用以線程編程的庫(kù)，如 boost，將不會(huì)在本文中提及。本文中主要涉及的題材包括線程開發(fā)中的線程管理，互斥變量，條件變量等。進(jìn)程概念將不會(huì)在本文中涉及。
?
Linux 上線程開發(fā) API 的概要介紹
?
多線程開發(fā)在 Linux 平臺(tái)上已經(jīng)有成熟的 Pthread 庫(kù)支持。其涉及的多線程開發(fā)的最基本概念主要包含三點(diǎn)：線程，互斥鎖，條件。其中，線程操作又分線程的創(chuàng)建，退出，等待 3 種。互斥鎖則包括 4 種操作，分別是創(chuàng)建，銷毀，加鎖和解鎖。條件操作有 5 種操作：創(chuàng)建，銷毀，觸發(fā)，廣播和等待。其他的一些線程擴(kuò)展概念，如信號(hào)燈等，都可以通過上面的三個(gè)基本元素的基本操作封裝出來。
?
線程，互斥鎖，條件在 Linux 平臺(tái)上對(duì)應(yīng)的 API 可以用表 1 歸納。為了方便熟悉 Windows 線程編程的讀者熟悉 Linux 多線程開發(fā)的 API，我們?cè)诒碇型瑫r(shí)也列出 Windows SDK 庫(kù)中所對(duì)應(yīng)的 API 名稱。
?
表 1. 線程函數(shù)列表
?
| 線程 | 創(chuàng)建 | pthread_create | CreateThread |
| 退出 | pthread_exit | ThreadExit | |
| 等待 | pthread_join | WaitForSingleObject | |
| 互斥鎖 | 創(chuàng)建 | pthread_mutex_init | CreateMutex |
| 銷毀 | pthread_mutex_destroy | CloseHandle | |
| 加鎖 | pthread_mutex_lock | WaitForSingleObject | |
| 解鎖 | pthread_mutex_unlock | ReleaseMutex | |
| 條件 | 創(chuàng)建 | pthread_cond_init | CreateEvent |
| 銷毀 | pthread_cond_destroy | CloseHandle | |
| 觸發(fā) | pthread_cond_signal | SetEvent | |
| 廣播 | pthread_cond_broadcast | SetEvent / ResetEvent | |
| 等待 | pthread_cond_wait / pthread_cond_timedwait | SingleObjectAndWait |
?
多線程開發(fā)在 Linux 平臺(tái)上已經(jīng)有成熟的 Pthread 庫(kù)支持。其涉及的多線程開發(fā)的最基本概念主要包含三點(diǎn)：線程，互斥鎖，條件。其中，線程操作又分線程的創(chuàng)建，退出，等待 3 種。互斥鎖則包括 4 種操作，分別是創(chuàng)建，銷毀，加鎖和解鎖。條件操作有 5 種操作：創(chuàng)建，銷毀，觸發(fā)，廣播和等待。其他的一些線程擴(kuò)展概念，如信號(hào)燈等，都可以通過上面的三個(gè)基本元素的基本操作封裝出來。
?
Linux 線程編程中的 5 條經(jīng)驗(yàn)
?
盡量設(shè)置 recursive 屬性以初始化 Linux 的互斥變量
?
互斥鎖是多線程編程中基本的概念，在開發(fā)中被廣泛使用。其調(diào)用次序?qū)哟吻逦?jiǎn)單：建鎖，加鎖，解鎖，銷毀鎖。但是需要注意的是，與諸如 Windows 平臺(tái)的互斥變量不同，在默認(rèn)情況下，Linux 下的同一線程無法對(duì)同一互斥鎖進(jìn)行遞歸加速，否則將發(fā)生死鎖。
?
所謂遞歸加鎖，就是在同一線程中試圖對(duì)互斥鎖進(jìn)行兩次或兩次以上的行為。其場(chǎng)景在 Linux 平臺(tái)上的代碼可由清單 1 所示。
?
清單 1. Linux 重復(fù)對(duì)互斥鎖加鎖實(shí)例
?
// 通過默認(rèn)條件建鎖 ????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);?
在以上代碼場(chǎng)景中，問題將出現(xiàn)在第二次加鎖操作。由于在默認(rèn)情況下，Linux 不允許同一線程遞歸加鎖，因此在第二次加鎖操作時(shí)線程將出現(xiàn)死鎖。
?
Linux 互斥變量這種奇怪的行為或許對(duì)于特定的某些場(chǎng)景會(huì)所有用處，但是對(duì)于大多數(shù)情況下看起來更像是程序的一個(gè) bug 。畢竟，在同一線程中對(duì)同一互斥鎖進(jìn)行遞歸加鎖在尤其是二次開發(fā)中經(jīng)常會(huì)需要。
?
這個(gè)問題與互斥鎖的中的默認(rèn) recursive 屬性有關(guān)。解決問題的方法就是顯式地在互斥變量初始化時(shí)將設(shè)置起 recursive 屬性。基于此，以上代碼其實(shí)稍作修改就可以很好的運(yùn)行，只需要在初始化鎖的時(shí)候加設(shè)置一個(gè)屬性。請(qǐng)看清單 2 。
?
清單 2. 設(shè)置互斥鎖 recursive 屬性實(shí)例
?
pthread_mutexattr_init(&attr); ????// 設(shè)置 recursive 屬性 ????pthread_mutexattr_settype(&attr,PTHREAD_MUTEX_RECURSIVE_NP); ????pthread_mutex_init(theMutex,&attr);?
因此，建議盡量設(shè)置 recursive 屬性以初始化 Linux 的互斥鎖，這樣既可以解決同一線程遞歸加鎖的問題，又可以避免很多情況下死鎖的發(fā)生。這樣做還有一個(gè)額外的好處，就是可以讓 Windows 和 Linux 下讓鎖的表現(xiàn)統(tǒng)一。
?
注意 Linux 平臺(tái)上觸發(fā)條件變量的自動(dòng)復(fù)位問題
?
條件變量的置位和復(fù)位有兩種常用模型：第一種模型是當(dāng)條件變量置位（signaled）以后，如果當(dāng)前沒有線程在等待，其狀態(tài)會(huì)保持為置位（signaled），直到有等待的線程進(jìn)入被觸發(fā)，其狀態(tài)才會(huì)變?yōu)閺?fù)位（unsignaled），這種模型的采用以 Windows 平臺(tái)上的 Auto-set Event 為代表。其狀態(tài)變化如圖 1 所示：
?
圖 1. Windows 的條件變量狀態(tài)變化流程
第二種模型則是 Linux 平臺(tái)的 Pthread 所采用的模型，當(dāng)條件變量置位（signaled）以后，即使當(dāng)前沒有任何線程在等待，其狀態(tài)也會(huì)恢復(fù)為復(fù)位（unsignaled）狀態(tài)。其狀態(tài)變化如圖 2 所示：
?
圖 2. Linux 的條件變量狀態(tài)變化流程
具體來說，Linux 平臺(tái)上 Pthread 下的條件變量狀態(tài)變化模型是這樣工作的：調(diào)用 pthread_cond_signal() 釋放被條件阻塞的線程時(shí)，無論存不存在被阻塞的線程，條件都將被重新復(fù)位，下一個(gè)被條件阻塞的線程將不受影響。而對(duì)于 Windows，當(dāng)調(diào)用 SetEvent 觸發(fā) Auto-reset 的 Event 條件時(shí)，如果沒有被條件阻塞的線程，那么條件將維持在觸發(fā)狀態(tài)，直到有新的線程被條件阻塞并被釋放為止。
?
這種差異性對(duì)于那些熟悉 Windows 平臺(tái)上的條件變量狀態(tài)模型而要開發(fā) Linux 平臺(tái)上多線程的程序員來說可能會(huì)造成意想不到的尷尬結(jié)果。試想要實(shí)現(xiàn)一個(gè)旅客坐出租車的程序：旅客在路邊等出租車，調(diào)用條件等待。出租車來了，將觸發(fā)條件，旅客停止等待并上車。一個(gè)出租車只能搭載一波乘客，于是我們使用單一觸發(fā)的條件變量。這個(gè)實(shí)現(xiàn)邏輯在第一個(gè)模型下即使出租車先到，也不會(huì)有什么問題，其過程如圖 3 所示：
?
圖 3. 采用 Windows 條件變量模型的出租車實(shí)例流程
然而如果按照這個(gè)思路來在 Linux 上來實(shí)現(xiàn)，代碼看起來可能是清單 3 這樣。
?
清單 3. Linux 出租車案例代碼實(shí)例
?
…… ?// 提示出租車到達(dá)的條件變量 ?pthread_cond_t taxiCond; ?// 同步鎖 ?pthread_mutex_t taxiMutex; ?// 旅客到達(dá)等待出租車 ?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 ); ?} ?// 出租車到達(dá) ?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; ?}?
好的，運(yùn)行一下，看看結(jié)果如清單 4 。
?
清單 4. 程序結(jié)果輸出
?
Taxi Jack arrives. ????Traveler Susan needs a taxi now! ????Taxi Mike arrives. ????Traveler Susan now got a taxi.?
其過程如圖 4 所示：
?
圖 4. 采用 Linux 條件變量模型的出租車實(shí)例流程
通過對(duì)比結(jié)果，你會(huì)發(fā)現(xiàn)同樣的邏輯，在 Linux 平臺(tái)上運(yùn)行的結(jié)果卻完全是兩樣。對(duì)于在 Windows 平臺(tái)上的模型一， Jack 開著出租車到了站臺(tái)，觸發(fā)條件變量。如果沒顧客，條件變量將維持觸發(fā)狀態(tài)，也就是說 Jack 停下車在那里等著。直到 Susan 小姐來了站臺(tái)，執(zhí)行等待條件來找出租車。 Susan 搭上 Jack 的出租車離開，同時(shí)條件變量被自動(dòng)復(fù)位。
?
但是到了 Linux 平臺(tái)，問題就來了，Jack 到了站臺(tái)一看沒人，觸發(fā)的條件變量被直接復(fù)位，于是 Jack 排在等待隊(duì)列里面。來遲一秒的 Susan 小姐到了站臺(tái)卻看不到在那里等待的 Jack，只能等待，直到 Mike 開車趕到，重新觸發(fā)條件變量，Susan 才上了 Mike 的車。這對(duì)于在排隊(duì)系統(tǒng)前面的 Jack 是不公平的，而問題癥結(jié)是在于 Linux 平臺(tái)上條件變量觸發(fā)的自動(dòng)復(fù)位引起的一個(gè) Bug 。
?
條件變量在 Linux 平臺(tái)上的這種模型很難說好壞。但是在實(shí)際開發(fā)中，我們可以對(duì)代碼稍加改進(jìn)就可以避免這種差異的發(fā)生。由于這種差異只發(fā)生在觸發(fā)沒有被線程等待在條件變量的時(shí)刻，因此我們只需要掌握好觸發(fā)的時(shí)機(jī)即可。最簡(jiǎn)單的做法是增加一個(gè)計(jì)數(shù)器記錄等待線程的個(gè)數(shù)，在決定觸發(fā)條件變量前檢查下該變量即可。改進(jìn)后 Linux 函數(shù)如清單 5 所示。
?
清單 5. Linux 出租車案例代碼實(shí)例
?
…… ?// 提示出租車到達(dá)的條件變量 ?pthread_cond_t taxiCond; ?// 同步鎖 ?pthread_mutex_t taxiMutex; ?// 旅客人數(shù)，初始為 0 ?int travelerCount=0; ?// 旅客到達(dá)等待出租車 ?void * traveler_arrive(void * name) { ????cout<< ” Traveler: ” <<(char *)name<< ” needs a taxi now! ” <<endl; ????pthread_mutex_lock(&taxiMutex); ????// 提示旅客人數(shù)增加 ????travelerCount++; ????pthread_cond_wait (&taxiCond, &taxiMutex); ????pthread_mutex_unlock (&taxiMutex); ????cout<< ” Traveler: ” << (char *)name << ” now got a taxi! ” <<endl; ????pthread_exit( (void *)0 ); ?} ?// 出租車到達(dá) ?void * taxi_arrive(void *name) ?{ ????cout<< ” Taxi ” <<(char *)name<< ” arrives. ” <<endl; ?while(true) ?{ ????????pthread_mutex_lock(&taxiMutex); ????????// 當(dāng)發(fā)現(xiàn)已經(jīng)有旅客在等待時(shí)，才觸發(fā)條件變量 ????????if(travelerCount>0) ????????{ ????????????pthread_cond_signal(&taxtCond); ????????????pthread_mutex_unlock (&taxiMutex); ????????????break; ????????} ????????pthread_mutex_unlock (&taxiMutex); ????} ????pthread_exit( (void *)0 ); ?}?
因此我們建議在 Linux 平臺(tái)上要出發(fā)條件變量之前要檢查是否有等待的線程，只有當(dāng)有線程在等待時(shí)才對(duì)條件變量進(jìn)行觸發(fā)。
?
注意條件返回時(shí)互斥鎖的解鎖問題
?
在 Linux 調(diào)用 pthread_cond_wait 進(jìn)行條件變量等待操作時(shí)，我們?cè)黾右粋€(gè)互斥變量參數(shù)是必要的，這是為了避免線程間的競(jìng)爭(zhēng)和饑餓情況。但是當(dāng)條件等待返回時(shí)候，需要注意的是一定不要遺漏對(duì)互斥變量進(jìn)行解鎖。
?
Linux 平臺(tái)上的 pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex) 函數(shù)返回時(shí)，互斥鎖 mutex 將處于鎖定狀態(tài)。因此之后如果需要對(duì)臨界區(qū)數(shù)據(jù)進(jìn)行重新訪問，則沒有必要對(duì) mutex 就行重新加鎖。但是，隨之而來的問題是，每次條件等待以后需要加入一步手動(dòng)的解鎖操作。正如前文中乘客等待出租車的 Linux 代碼如清單 6 所示：
?
清單 6. 條件變量返回后的解鎖實(shí)例
?
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 ); ?}?
這一點(diǎn)對(duì)于熟悉 Windows 平臺(tái)多線程開發(fā)的開發(fā)者來說尤為重要。 Windows 上的 SignalObjectAndWait() 函數(shù)是常與 Linux 平臺(tái)上的 pthread_cond_wait() 函數(shù)被看作是跨平臺(tái)編程時(shí)的一對(duì)等價(jià)函數(shù)。但是需要注意的是，兩個(gè)函數(shù)退出時(shí)的狀態(tài)是不一樣的。在 Windows 平臺(tái)上，SignalObjectAndWait(HANDLE a, HANDLE b, …… ) 方法在調(diào)用結(jié)束返回時(shí)的狀態(tài)是 a 和 b 都是置位（signaled）狀態(tài)，在普遍的使用方法中，a 經(jīng)常是一個(gè) Mutex 變量，在這種情況下，當(dāng)返回時(shí)，Mutex a 處于解鎖狀態(tài)（signaled），Event b 處于置位狀態(tài)（signaled）, 因此，對(duì)于 Mutex a 而言，我們不需要考慮解鎖的問題。而且，在 SignalObjectAndWait() 之后，如果需要對(duì)臨界區(qū)數(shù)據(jù)進(jìn)行重新訪問，都需要調(diào)用 WaitForSingleObject() 重新加鎖。這一點(diǎn)剛好與 Linux 下的 pthread_cond_wait() 完全相反。
?
Linux 對(duì)于 Windows 的這一點(diǎn)額外解鎖的操作區(qū)別很重要，一定得牢記。否則從 Windows 移植到 Linux 上的條件等待操作一旦忘了結(jié)束后的解鎖操作，程序?qū)⒖隙〞?huì)發(fā)生死鎖。
?
等待的絕對(duì)時(shí)間問題
?
超時(shí)是多線程編程中一個(gè)常見的概念。例如，當(dāng)你在 Linux 平臺(tái)下使用 pthread_cond_timedwait() 時(shí)就需要指定超時(shí)這個(gè)參數(shù)，以便這個(gè) API 的調(diào)用者最多只被阻塞指定的時(shí)間間隔。但是如果你是第一次使用這個(gè) API 時(shí)，首先你需要了解的就是這個(gè) API 當(dāng)中超時(shí)參數(shù)的特殊性（就如本節(jié)標(biāo)題所提示的那樣）。我們首先來看一下這個(gè) API 的定義。 pthread_cond_timedwait() 定義請(qǐng)看清單 7 。
?
清單 7. pthread_cond_timedwait() 函數(shù)定義
?
int pthread_cond_timedwait(pthread_cond_t *restrict cond, ??????????????pthread_mutex_t *restrict mutex, ??????????????const struct timespec *restrict abstime);?
參數(shù) abstime 在這里用來表示和超時(shí)時(shí)間相關(guān)的一個(gè)參數(shù)，但是需要注意的是它所表示的是一個(gè)絕對(duì)時(shí)間，而不是一個(gè)時(shí)間間隔數(shù)值，只有當(dāng)系統(tǒng)的當(dāng)前時(shí)間達(dá)到或者超過 abstime 所表示的時(shí)間時(shí)，才會(huì)觸發(fā)超時(shí)事件。這對(duì)于擁有 Windows 平臺(tái)線程開發(fā)經(jīng)驗(yàn)的人來說可能尤為困惑。因?yàn)?Windows 平臺(tái)下所有的 API 等待參數(shù)（如 SignalObjectAndWait，等）都是相對(duì)時(shí)間，
?
假設(shè)我們指定相對(duì)的超時(shí)時(shí)間參數(shù)如 dwMilliseconds （單位毫秒）來調(diào)用和超時(shí)相關(guān)的函數(shù)，這樣就需要將 dwMilliseconds 轉(zhuǎn)化為 Linux 下的絕對(duì)時(shí)間參數(shù) abstime 使用。常用的轉(zhuǎn)換方法如清單 8 所示：
?
清單 8. 相對(duì)時(shí)間到絕對(duì)時(shí)間轉(zhuǎn)換實(shí)例
?
/* 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 的絕對(duì)時(shí)間看似簡(jiǎn)單明了，卻是開發(fā)中一個(gè)非常隱晦的陷阱。而且一旦你忘了時(shí)間轉(zhuǎn)換，可以想象，等待你的錯(cuò)誤將是多么的令人頭疼：如果忘了把相對(duì)時(shí)間轉(zhuǎn)換成絕對(duì)時(shí)間，相當(dāng)于你告訴系統(tǒng)你所等待的超時(shí)時(shí)間是過去式的 1970 年 1 月 1 號(hào)某個(gè)時(shí)間段，于是操作系統(tǒng)毫不猶豫馬上送給你一個(gè) timeout 的返回值，然后你會(huì)舉著拳頭抱怨為什么另外一個(gè)同步線程耗時(shí)居然如此之久，并一頭扎進(jìn)尋找耗時(shí)原因的深淵里。
?
正確處理 Linux 平臺(tái)下的線程結(jié)束問題
?
在 Linux 平臺(tái)下，當(dāng)處理線程結(jié)束時(shí)需要注意的一個(gè)問題就是如何讓一個(gè)線程善始善終，讓其所占資源得到正確釋放。在 Linux 平臺(tái)默認(rèn)情況下，雖然各個(gè)線程之間是相互獨(dú)立的，一個(gè)線程的終止不會(huì)去通知或影響其他的線程。但是已經(jīng)終止的線程的資源并不會(huì)隨著線程的終止而得到釋放，我們需要調(diào)用 pthread_join() 來獲得另一個(gè)線程的終止?fàn)顟B(tài)并且釋放該線程所占的資源。 Pthread_join() 函數(shù)的定義如清單 9 。
?
清單 9. pthread_join 函數(shù)定義
?
int pthread_join(pthread_t th, void **thread_return);?
調(diào)用該函數(shù)的線程將掛起，等待 th 所表示的線程的結(jié)束。 thread_return 是指向線程 th 返回值的指針。需要注意的是 th 所表示的線程必須是 joinable 的，即處于非 detached（游離）狀態(tài)；并且只可以有唯一的一個(gè)線程對(duì) th 調(diào)用 pthread_join() 。如果 th 處于 detached 狀態(tài)，那么對(duì) th 的 pthread_join() 調(diào)用將返回錯(cuò)誤。
?
如果你壓根兒不關(guān)心一個(gè)線程的結(jié)束狀態(tài)，那么也可以將一個(gè)線程設(shè)置為 detached 狀態(tài)，從而來讓操作系統(tǒng)在該線程結(jié)束時(shí)來回收它所占的資源。將一個(gè)線程設(shè)置為 detached 狀態(tài)可以通過兩種方式來實(shí)現(xiàn)。一種是調(diào)用 pthread_detach() 函數(shù)，可以將線程 th 設(shè)置為 detached 狀態(tài)。其申明如清單 10 。
?
清單 10. pthread_detach 函數(shù)定義
?
int pthread_detach(pthread_t th);?
另一種方法是在創(chuàng)建線程時(shí)就將它設(shè)置為 detached 狀態(tài)，首先初始化一個(gè)線程屬性變量，然后將其設(shè)置為 detached 狀態(tài)，最后將它作為參數(shù)傳入線程創(chuàng)建函數(shù) pthread_create()，這樣所創(chuàng)建出來的線程就直接處于 detached 狀態(tài)。方法如清單 11 。
?
清單 11. 創(chuàng)建 detach 線程代碼實(shí)例
?
………………………………… .. ????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 時(shí)避免線程的資源在線程結(jié)束時(shí)不能得到正確釋放，從而避免產(chǎn)生潛在的內(nèi)存泄漏問題，在對(duì)待線程結(jié)束時(shí)，要確保該線程處于 detached 狀態(tài)，否著就需要調(diào)用 pthread_join() 函數(shù)來對(duì)其進(jìn)行資源回收。
?
總結(jié)與補(bǔ)充
?
本文以上部分詳細(xì)介紹了 Linux 的多線程編程的 5 條高效開發(fā)經(jīng)驗(yàn)。另外你也可以考慮嘗試其他一些開源類庫(kù)來進(jìn)行線程開發(fā)。
?
1. Boost 庫(kù)
?
Boost 庫(kù)來自于由 C++ 標(biāo)準(zhǔn)委員會(huì)類庫(kù)工作組成員發(fā)起，致力于為 C++ 開發(fā)新的類庫(kù)的 Boost 組織。雖然該庫(kù)本身并不是針對(duì)多線程而產(chǎn)生，但是發(fā)展至今，其已提供了比較全面的多線程編程的 API 支持。 Boost 庫(kù)對(duì)于多線程支持的 API 風(fēng)格上更類似于 Linux 的 Pthread 庫(kù)，差別在于其將線程，互斥鎖，條件等線程開發(fā)概念都封裝成了 C++ 類，以方便開發(fā)調(diào)用。 Boost 庫(kù)目前對(duì)跨平臺(tái)支持的很不錯(cuò)，不僅支持 Windows 和 Linux ，還支持各種商用的 Unix 版本。如果開發(fā)者想使用高穩(wěn)定性的統(tǒng)一線程編程接口減輕跨平臺(tái)開發(fā)的難度， Boost 庫(kù)將是首選。
?
2. ACE
?
ACE 全稱是 ADAPTIVE Communication Environment，它是一個(gè)免費(fèi)的，開源的，面向?qū)ο蟮墓ぞ呖蚣?#xff0c;用以開發(fā)并發(fā)訪問的軟件。由于 ACE 最初是面向網(wǎng)絡(luò)服務(wù)端的編程開發(fā)，因此對(duì)于線程開發(fā)的工具庫(kù)它也能提供很全面的支持。其支持的平臺(tái)也很全面，包括 Windows，Linux 和各種版本 Unix 。 ACE 的唯一問題是如果僅僅是用于線程編程，其似乎顯得有些過于重量級(jí)。而且其較復(fù)雜的配置也讓其部署對(duì)初學(xué)者而言并非易事。
?
相關(guān)主題
?
- IBM Developerworks 以下系列文章系列詳細(xì)介紹了如何對(duì)線程程序從 Windows 到 Linux 上進(jìn)行移植。
- 文章《Strategies for Implementing POSIX Condition Variables on Win32》很全面的介紹了如何在 Windows 上實(shí)現(xiàn) POSIX condition。
- 參閱 Boost 庫(kù)的官方網(wǎng)站
- 參閱 ACE 庫(kù)的官方網(wǎng)站
?
?
?
?
?
Linux 線程實(shí)現(xiàn)機(jī)制分析
?
?
一.基礎(chǔ)知識(shí)：線程和進(jìn)程
?
按照教科書上的定義，進(jìn)程是資源管理的最小單位，線程是程序執(zhí)行的最小單位。在操作系統(tǒng)設(shè)計(jì)上，從進(jìn)程演化出線程，最主要的目的就是更好的支持SMP以及減小（進(jìn)程/線程）上下文切換開銷。
?
無論按照怎樣的分法，一個(gè)進(jìn)程至少需要一個(gè)線程作為它的指令執(zhí)行體，進(jìn)程管理著資源（比如cpu、內(nèi)存、文件等等），而將線程分配到某個(gè)cpu上執(zhí)行。一個(gè)進(jìn)程當(dāng)然可以擁有多個(gè)線程，此時(shí)，如果進(jìn)程運(yùn)行在SMP機(jī)器上，它就可以同時(shí)使用多個(gè)cpu來執(zhí)行各個(gè)線程，達(dá)到最大程度的并行，以提高效率；同時(shí)，即使是在單cpu的機(jī)器上，采用多線程模型來設(shè)計(jì)程序，正如當(dāng)年采用多進(jìn)程模型代替單進(jìn)程模型一樣，使設(shè)計(jì)更簡(jiǎn)潔、功能更完備，程序的執(zhí)行效率也更高，例如采用多個(gè)線程響應(yīng)多個(gè)輸入，而此時(shí)多線程模型所實(shí)現(xiàn)的功能實(shí)際上也可以用多進(jìn)程模型來實(shí)現(xiàn)，而與后者相比，線程的上下文切換開銷就比進(jìn)程要小多了，從語義上來說，同時(shí)響應(yīng)多個(gè)輸入這樣的功能，實(shí)際上就是共享了除cpu以外的所有資源的。
?
針對(duì)線程模型的兩大意義，分別開發(fā)出了核心級(jí)線程和用戶級(jí)線程兩種線程模型，分類的標(biāo)準(zhǔn)主要是線程的調(diào)度者在核內(nèi)還是在核外。前者更利于并發(fā)使用多處理器的資源，而后者則更多考慮的是上下文切換開銷。在目前的商用系統(tǒng)中，通常都將兩者結(jié)合起來使用，既提供核心線程以滿足smp系統(tǒng)的需要，也支持用線程庫(kù)的方式在用戶態(tài)實(shí)現(xiàn)另一套線程機(jī)制，此時(shí)一個(gè)核心線程同時(shí)成為多個(gè)用戶態(tài)線程的調(diào)度者。正如很多技術(shù)一樣，"混合"通常都能帶來更高的效率，但同時(shí)也帶來更大的實(shí)現(xiàn)難度，出于"簡(jiǎn)單"的設(shè)計(jì)思路，Linux從一開始就沒有實(shí)現(xiàn)混合模型的計(jì)劃，但它在實(shí)現(xiàn)上采用了另一種思路的"混合"。
?
在線程機(jī)制的具體實(shí)現(xiàn)上，可以在操作系統(tǒng)內(nèi)核上實(shí)現(xiàn)線程，也可以在核外實(shí)現(xiàn)，后者顯然要求核內(nèi)至少實(shí)現(xiàn)了進(jìn)程，而前者則一般要求在核內(nèi)同時(shí)也支持進(jìn)程。核心級(jí)線程模型顯然要求前者的支持，而用戶級(jí)線程模型則不一定基于后者實(shí)現(xiàn)。這種差異，正如前所述，是兩種分類方式的標(biāo)準(zhǔn)不同帶來的。
?
當(dāng)核內(nèi)既支持進(jìn)程也支持線程時(shí)，就可以實(shí)現(xiàn)線程-進(jìn)程的"多對(duì)多"模型，即一個(gè)進(jìn)程的某個(gè)線程由核內(nèi)調(diào)度，而同時(shí)它也可以作為用戶級(jí)線程池的調(diào)度者，選擇合適的用戶級(jí)線程在其空間中運(yùn)行。這就是前面提到的"混合"線程模型，既可滿足多處理機(jī)系統(tǒng)的需要，也可以最大限度的減小調(diào)度開銷。絕大多數(shù)商業(yè)操作系統(tǒng)（如Digital Unix、Solaris、Irix）都采用的這種能夠完全實(shí)現(xiàn)POSIX1003.1c標(biāo)準(zhǔn)的線程模型。在核外實(shí)現(xiàn)的線程又可以分為"一對(duì)一"、"多對(duì)一"兩種模型，前者用一個(gè)核心進(jìn)程（也許是輕量進(jìn)程）對(duì)應(yīng)一個(gè)線程，將線程調(diào)度等同于進(jìn)程調(diào)度，交給核心完成，而后者則完全在核外實(shí)現(xiàn)多線程，調(diào)度也在用戶態(tài)完成。后者就是前面提到的單純的用戶級(jí)線程模型的實(shí)現(xiàn)方式，顯然，這種核外的線程調(diào)度器實(shí)際上只需要完成線程運(yùn)行棧的切換，調(diào)度開銷非常小，但同時(shí)因?yàn)楹诵男盘?hào)（無論是同步的還是異步的）都是以進(jìn)程為單位的，因而無法定位到線程，所以這種實(shí)現(xiàn)方式不能用于多處理器系統(tǒng)，而這個(gè)需求正變得越來越大，因此，在現(xiàn)實(shí)中，純用戶級(jí)線程的實(shí)現(xiàn)，除算法研究目的以外，幾乎已經(jīng)消失了。
?
Linux內(nèi)核只提供了輕量進(jìn)程的支持，限制了更高效的線程模型的實(shí)現(xiàn)，但Linux著重優(yōu)化了進(jìn)程的調(diào)度開銷，一定程度上也彌補(bǔ)了這一缺陷。目前最流行的線程機(jī)制LinuxThreads所采用的就是線程-進(jìn)程"一對(duì)一"模型，調(diào)度交給核心，而在用戶級(jí)實(shí)現(xiàn)一個(gè)包括信號(hào)處理在內(nèi)的線程管理機(jī)制。Linux-LinuxThreads的運(yùn)行機(jī)制正是本文的描述重點(diǎn)。
?
二.Linux 2.4內(nèi)核中的輕量進(jìn)程實(shí)現(xiàn)
?
最初的進(jìn)程定義都包含程序、資源及其執(zhí)行三部分，其中程序通常指代碼，資源在操作系統(tǒng)層面上通常包括內(nèi)存資源、IO資源、信號(hào)處理等部分，而程序的執(zhí)行通常理解為執(zhí)行上下文，包括對(duì)cpu的占用，后來發(fā)展為線程。在線程概念出現(xiàn)以前，為了減小進(jìn)程切換的開銷，操作系統(tǒng)設(shè)計(jì)者逐漸修正進(jìn)程的概念，逐漸允許將進(jìn)程所占有的資源從其主體剝離出來，允許某些進(jìn)程共享一部分資源，例如文件、信號(hào)，數(shù)據(jù)內(nèi)存，甚至代碼，這就發(fā)展出輕量進(jìn)程的概念。Linux內(nèi)核在2.0.x版本就已經(jīng)實(shí)現(xiàn)了輕量進(jìn)程，應(yīng)用程序可以通過一個(gè)統(tǒng)一的clone()系統(tǒng)調(diào)用接口，用不同的參數(shù)指定創(chuàng)建輕量進(jìn)程還是普通進(jìn)程。在內(nèi)核中，clone()調(diào)用經(jīng)過參數(shù)傳遞和解釋后會(huì)調(diào)用do_fork()，這個(gè)核內(nèi)函數(shù)同時(shí)也是fork()、vfork()系統(tǒng)調(diào)用的最終實(shí)現(xiàn)：
?
<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將導(dǎo)致不同的行為，對(duì)于LinuxThreads，它使用（CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND）參數(shù)來調(diào)用clone()創(chuàng)建"線程"，表示共享內(nèi)存、共享文件系統(tǒng)訪問計(jì)數(shù)、共享文件描述符表，以及共享信號(hào)處理方式。本節(jié)就針對(duì)這幾個(gè)參數(shù)，看看Linux內(nèi)核是如何實(shí)現(xiàn)這些資源的共享的。
?
1.CLONE_VM
?
do_fork()需要調(diào)用copy_mm()來設(shè)置task_struct中的mm和active_mm項(xiàng)，這兩個(gè)mm_struct數(shù)據(jù)與進(jìn)程所關(guān)聯(lián)的內(nèi)存空間相對(duì)應(yīng)。如果do_fork()時(shí)指定了CLONE_VM開關(guān)，copy_mm()將把新的task_struct中的mm和active_mm設(shè)置成與current的相同，同時(shí)提高該mm_struct的使用者數(shù)目（mm_struct::mm_users）。也就是說，輕量級(jí)進(jìn)程與父進(jìn)程共享內(nèi)存地址空間，由下圖示意可以看出mm_struct在進(jìn)程中的地位：
?
?
2.CLONE_FS
?
task_struct中利用fs（struct fs_struct *）記錄了進(jìn)程所在文件系統(tǒng)的根目錄和當(dāng)前目錄信息，do_fork()時(shí)調(diào)用copy_fs()復(fù)制了這個(gè)結(jié)構(gòu)；而對(duì)于輕量級(jí)進(jìn)程則僅增加fs->count計(jì)數(shù)，與父進(jìn)程共享相同的fs_struct。也就是說，輕量級(jí)進(jìn)程沒有獨(dú)立的文件系統(tǒng)相關(guān)的信息，進(jìn)程中任何一個(gè)線程改變當(dāng)前目錄、根目錄等信息都將直接影響到其他線程。
?
3.CLONE_FILES
?
一個(gè)進(jìn)程可能打開了一些文件，在進(jìn)程結(jié)構(gòu)task_struct中利用files（struct files_struct *）來保存進(jìn)程打開的文件結(jié)構(gòu)（struct file）信息，do_fork()中調(diào)用了copy_files()來處理這個(gè)進(jìn)程屬性；輕量級(jí)進(jìn)程與父進(jìn)程是共享該結(jié)構(gòu)的，copy_files()時(shí)僅增加files->count計(jì)數(shù)。這一共享使得任何線程都能訪問進(jìn)程所維護(hù)的打開文件，對(duì)它們的操作會(huì)直接反映到進(jìn)程中的其他線程。
?
4.CLONE_SIGHAND
?
每一個(gè)Linux進(jìn)程都可以自行定義對(duì)信號(hào)的處理方式，在task_struct中的sig（struct signal_struct）中使用一個(gè)struct k_sigaction結(jié)構(gòu)的數(shù)組來保存這個(gè)配置信息，do_fork()中的copy_sighand()負(fù)責(zé)復(fù)制該信息；輕量級(jí)進(jìn)程不進(jìn)行復(fù)制，而僅僅增加signal_struct::count計(jì)數(shù)，與父進(jìn)程共享該結(jié)構(gòu)。也就是說，子進(jìn)程與父進(jìn)程的信號(hào)處理方式完全相同，而且可以相互更改。
?
do_fork()中所做的工作很多，在此不詳細(xì)描述。對(duì)于SMP系統(tǒng)，所有的進(jìn)程fork出來后，都被分配到與父進(jìn)程相同的cpu上，一直到該進(jìn)程被調(diào)度時(shí)才會(huì)進(jìn)行cpu選擇。
?
盡管Linux支持輕量級(jí)進(jìn)程，但并不能說它就支持核心級(jí)線程，因?yàn)長(zhǎng)inux的"線程"和"進(jìn)程"實(shí)際上處于一個(gè)調(diào)度層次，共享一個(gè)進(jìn)程標(biāo)識(shí)符空間，這種限制使得不可能在Linux上實(shí)現(xiàn)完全意義上的POSIX線程機(jī)制，因此眾多的Linux線程庫(kù)實(shí)現(xiàn)嘗試都只能盡可能實(shí)現(xiàn)POSIX的絕大部分語義，并在功能上盡可能逼近。
?
三.LinuxThread的線程機(jī)制
?
LinuxThreads是目前Linux平臺(tái)上使用最為廣泛的線程庫(kù)，由Xavier Leroy (Xavier.Leroy@inria.fr)負(fù)責(zé)開發(fā)完成，并已綁定在GLIBC中發(fā)行。它所實(shí)現(xiàn)的就是基于核心輕量級(jí)進(jìn)程的"一對(duì)一"線程模型，一個(gè)線程實(shí)體對(duì)應(yīng)一個(gè)核心輕量級(jí)進(jìn)程，而線程之間的管理在核外函數(shù)庫(kù)中實(shí)現(xiàn)。
?
1.線程描述數(shù)據(jù)結(jié)構(gòu)及實(shí)現(xiàn)限制
?
LinuxThreads定義了一個(gè)struct _pthread_descr_struct數(shù)據(jù)結(jié)構(gòu)來描述線程，并使用全局?jǐn)?shù)組變量__pthread_handles來描述和引用進(jìn)程所轄線程。在__pthread_handles中的前兩項(xiàng)，LinuxThreads定義了兩個(gè)全局的系統(tǒng)線程：__pthread_initial_thread和__pthread_manager_thread，并用__pthread_main_thread表征__pthread_manager_thread的父線程（初始為__pthread_initial_thread）。
?
struct _pthread_descr_struct是一個(gè)雙環(huán)鏈表結(jié)構(gòu)，__pthread_manager_thread所在的鏈表僅包括它一個(gè)元素，實(shí)際上，__pthread_manager_thread是一個(gè)特殊線程，LinuxThreads僅使用了其中的errno、p_pid、p_priority等三個(gè)域。而__pthread_main_thread所在的鏈則將進(jìn)程中所有用戶線程串在了一起。經(jīng)過一系列pthread_create()之后形成的__pthread_handles數(shù)組將如下圖所示：
?
?
新創(chuàng)建的線程將首先在__pthread_handles數(shù)組中占據(jù)一項(xiàng)，然后通過數(shù)據(jù)結(jié)構(gòu)中的鏈指針連入以__pthread_main_thread為首指針的鏈表中。這個(gè)鏈表的使用在介紹線程的創(chuàng)建和釋放的時(shí)候?qū)⑻岬健?/p>
?
LinuxThreads遵循POSIX1003.1c標(biāo)準(zhǔn)，其中對(duì)線程庫(kù)的實(shí)現(xiàn)進(jìn)行了一些范圍限制，比如進(jìn)程最大線程數(shù)，線程私有數(shù)據(jù)區(qū)大小等等。在LinuxThreads的實(shí)現(xiàn)中，基本遵循這些限制，但也進(jìn)行了一定的改動(dòng)，改動(dòng)的趨勢(shì)是放松或者說擴(kuò)大這些限制，使編程更加方便。這些限定宏主要集中在sysdeps/unix/sysv/linux/bits/local_lim.h（不同平臺(tái)使用的文件位置不同）中，包括如下幾個(gè)：
?
每進(jìn)程的私有數(shù)據(jù)key數(shù)，POSIX定義_POSIX_THREAD_KEYS_MAX為128，LinuxThreads使用PTHREAD_KEYS_MAX，1024；私有數(shù)據(jù)釋放時(shí)允許執(zhí)行的操作數(shù)，LinuxThreads與POSIX一致，定義PTHREAD_DESTRUCTOR_ITERATIONS為4；每進(jìn)程的線程數(shù)，POSIX定義為64，LinuxThreads增大到1024（PTHREAD_THREADS_MAX）；線程運(yùn)行棧最小空間大小，POSIX未指定，LinuxThreads使用PTHREAD_STACK_MIN，16384（字節(jié)）。
?
2.管理線程
?
"一對(duì)一"模型的好處之一是線程的調(diào)度由核心完成了，而其他諸如線程取消、線程間的同步等工作，都是在核外線程庫(kù)中完成的。在LinuxThreads中，專門為每一個(gè)進(jìn)程構(gòu)造了一個(gè)管理線程，負(fù)責(zé)處理線程相關(guān)的管理工作。當(dāng)進(jìn)程第一次調(diào)用pthread_create()創(chuàng)建一個(gè)線程的時(shí)候就會(huì)創(chuàng)建（__clone()）并啟動(dòng)管理線程。
?
在一個(gè)進(jìn)程空間內(nèi)，管理線程與其他線程之間通過一對(duì)"管理管道（manager_pipe[2]）"來通訊，該管道在創(chuàng)建管理線程之前創(chuàng)建，在成功啟動(dòng)了管理線程之后，管理管道的讀端和寫端分別賦給兩個(gè)全局變量__pthread_manager_reader和__pthread_manager_request，之后，每個(gè)用戶線程都通過__pthread_manager_request向管理線程發(fā)請(qǐng)求，但管理線程本身并沒有直接使用__pthread_manager_reader，管道的讀端（manager_pipe[0]）是作為__clone()的參數(shù)之一傳給管理線程的，管理線程的工作主要就是監(jiān)聽管道讀端，并對(duì)從中取出的請(qǐng)求作出反應(yīng)。
?
創(chuàng)建管理線程的流程如下所示：
（全局變量pthread_manager_request初值為-1）
?
?
初始化結(jié)束后，在__pthread_manager_thread中記錄了輕量級(jí)進(jìn)程號(hào)以及核外分配和管理的線程id，2*PTHREAD_THREADS_MAX+1這個(gè)數(shù)值不會(huì)與任何常規(guī)用戶線程id沖突。管理線程作為pthread_create()的調(diào)用者線程的子線程運(yùn)行，而pthread_create()所創(chuàng)建的那個(gè)用戶線程則是由管理線程來調(diào)用clone()創(chuàng)建，因此實(shí)際上是管理線程的子線程。（此處子線程的概念應(yīng)該當(dāng)作子進(jìn)程來理解。）
?
__pthread_manager()就是管理線程的主循環(huán)所在，在進(jìn)行一系列初始化工作后，進(jìn)入while(1)循環(huán)。在循環(huán)中，線程以2秒為timeout查詢（__poll()）管理管道的讀端。在處理請(qǐng)求前，檢查其父線程（也就是創(chuàng)建manager的主線程）是否已退出，如果已退出就退出整個(gè)進(jìn)程。如果有退出的子線程需要清理，則調(diào)用pthread_reap_children()清理。
?
然后才是讀取管道中的請(qǐng)求，根據(jù)請(qǐng)求類型執(zhí)行相應(yīng)操作（switch-case）。具體的請(qǐng)求處理，源碼中比較清楚，這里就不贅述了。
?
3.線程棧
?
在LinuxThreads中，管理線程的棧和用戶線程的棧是分離的，管理線程在進(jìn)程堆中通過malloc()分配一個(gè)THREAD_MANAGER_STACK_SIZE字節(jié)的區(qū)域作為自己的運(yùn)行棧。
?
用戶線程的棧分配辦法隨著體系結(jié)構(gòu)的不同而不同，主要根據(jù)兩個(gè)宏定義來區(qū)分，一個(gè)是NEED_SEPARATE_REGISTER_STACK，這個(gè)屬性僅在IA64平臺(tái)上使用；另一個(gè)是FLOATING_STACK宏，在i386等少數(shù)平臺(tái)上使用，此時(shí)用戶線程棧由系統(tǒng)決定具體位置并提供保護(hù)。與此同時(shí)，用戶還可以通過線程屬性結(jié)構(gòu)來指定使用用戶自定義的棧。因篇幅所限，這里只能分析i386平臺(tái)所使用的兩種棧組織方式：FLOATING_STACK方式和用戶自定義方式。
?
在FLOATING_STACK方式下，LinuxThreads利用mmap()從內(nèi)核空間中分配8MB空間（i386系統(tǒng)缺省的最大棧空間大小，如果有運(yùn)行限制（rlimit），則按照運(yùn)行限制設(shè)置），使用mprotect()設(shè)置其中第一頁(yè)為非訪問區(qū)。該8M空間的功能分配如下圖：
?
?
低地址被保護(hù)的頁(yè)面用來監(jiān)測(cè)棧溢出。
?
對(duì)于用戶指定的棧，在按照指針對(duì)界后，設(shè)置線程棧頂，并計(jì)算出棧底，不做保護(hù)，正確性由用戶自己保證。
?
不論哪種組織方式，線程描述結(jié)構(gòu)總是位于棧頂緊鄰堆棧的位置。
?
4.線程id和進(jìn)程id
?
每個(gè)LinuxThreads線程都同時(shí)具有線程id和進(jìn)程id，其中進(jìn)程id就是內(nèi)核所維護(hù)的進(jìn)程號(hào)，而線程id則由LinuxThreads分配和維護(hù)。
?
__pthread_initial_thread的線程id為PTHREAD_THREADS_MAX，__pthread_manager_thread的是2*PTHREAD_THREADS_MAX+1，第一個(gè)用戶線程的線程id為PTHREAD_THREADS_MAX+2，此后第n個(gè)用戶線程的線程id遵循以下公式：
tid=n*PTHREAD_THREADS_MAX+n+1
?
?
這種分配方式保證了進(jìn)程中所有的線程（包括已經(jīng)退出）都不會(huì)有相同的線程id，而線程id的類型pthread_t定義為無符號(hào)長(zhǎng)整型（unsigned long int），也保證了有理由的運(yùn)行時(shí)間內(nèi)線程id不會(huì)重復(fù)。
?
從線程id查找線程數(shù)據(jù)結(jié)構(gòu)是在pthread_handle()函數(shù)中完成的，實(shí)際上只是將線程號(hào)按PTHREAD_THREADS_MAX取模，得到的就是該線程在__pthread_handles中的索引。
?
5.線程的創(chuàng)建
?
在pthread_create()向管理線程發(fā)送REQ_CREATE請(qǐng)求之后，管理線程即調(diào)用pthread_handle_create()創(chuàng)建新線程。分配棧、設(shè)置thread屬性后，以pthread_start_thread()為函數(shù)入口調(diào)用__clone()創(chuàng)建并啟動(dòng)新線程。pthread_start_thread()讀取自身的進(jìn)程id號(hào)存入線程描述結(jié)構(gòu)中，并根據(jù)其中記錄的調(diào)度方法配置調(diào)度。一切準(zhǔn)備就緒后，再調(diào)用真正的線程執(zhí)行函數(shù)，并在此函數(shù)返回后調(diào)用pthread_exit()清理現(xiàn)場(chǎng)。
?
6.LinuxThreads的不足
?
由于Linux內(nèi)核的限制以及實(shí)現(xiàn)難度等等原因，LinuxThreads并不是完全POSIX兼容的，在它的發(fā)行README中有說明。
?
1)進(jìn)程id問題
?
這個(gè)不足是最關(guān)鍵的不足，引起的原因牽涉到LinuxThreads的"一對(duì)一"模型。
?
Linux內(nèi)核并不支持真正意義上的線程，LinuxThreads是用與普通進(jìn)程具有同樣內(nèi)核調(diào)度視圖的輕量級(jí)進(jìn)程來實(shí)現(xiàn)線程支持的。這些輕量級(jí)進(jìn)程擁有獨(dú)立的進(jìn)程id，在進(jìn)程調(diào)度、信號(hào)處理、IO等方面享有與普通進(jìn)程一樣的能力。在源碼閱讀者看來，就是Linux內(nèi)核的clone()沒有實(shí)現(xiàn)對(duì)CLONE_PID參數(shù)的支持。
?
在內(nèi)核do_fork()中對(duì)CLONE_PID的處理是這樣的：
?
? if (clone_flags & CLONE_PID) { ????????if (current->pid) ????????????????goto fork_out; }?
這段代碼表明，目前的Linux內(nèi)核僅在pid為0的時(shí)候認(rèn)可CLONE_PID參數(shù)，實(shí)際上，僅在SMP初始化，手工創(chuàng)建進(jìn)程的時(shí)候才會(huì)使用CLONE_PID參數(shù)。
?
按照POSIX定義，同一進(jìn)程的所有線程應(yīng)該共享一個(gè)進(jìn)程id和父進(jìn)程id，這在目前的"一對(duì)一"模型下是無法實(shí)現(xiàn)的。
?
2)信號(hào)處理問題
?
由于異步信號(hào)是內(nèi)核以進(jìn)程為單位分發(fā)的，而LinuxThreads的每個(gè)線程對(duì)內(nèi)核來說都是一個(gè)進(jìn)程，且沒有實(shí)現(xiàn)"線程組"，因此，某些語義不符合POSIX標(biāo)準(zhǔn)，比如沒有實(shí)現(xiàn)向進(jìn)程中所有線程發(fā)送信號(hào)，README對(duì)此作了說明。
?
如果核心不提供實(shí)時(shí)信號(hào)，LinuxThreads將使用SIGUSR1和SIGUSR2作為內(nèi)部使用的restart和cancel信號(hào)，這樣應(yīng)用程序就不能使用這兩個(gè)原本為用戶保留的信號(hào)了。在Linux kernel 2.1.60以后的版本都支持?jǐn)U展的實(shí)時(shí)信號(hào)（從_SIGRTMIN到_SIGRTMAX），因此不存在這個(gè)問題。
?
某些信號(hào)的缺省動(dòng)作難以在現(xiàn)行體系上實(shí)現(xiàn)，比如SIGSTOP和SIGCONT，LinuxThreads只能將一個(gè)線程掛起，而無法掛起整個(gè)進(jìn)程。
?
3)線程總數(shù)問題
?
LinuxThreads將每個(gè)進(jìn)程的線程最大數(shù)目定義為1024，但實(shí)際上這個(gè)數(shù)值還受到整個(gè)系統(tǒng)的總進(jìn)程數(shù)限制，這又是由于線程其實(shí)是核心進(jìn)程。
?
在kernel 2.4.x中，采用一套全新的總進(jìn)程數(shù)計(jì)算方法，使得總進(jìn)程數(shù)基本上僅受限于物理內(nèi)存的大小，計(jì)算公式在kernel/fork.c的fork_init()函數(shù)中：
?
max_threads = mempages / (THREAD_SIZE/PAGE_SIZE) / 8?
在i386上，THREAD_SIZE=2*PAGE_SIZE，PAGE_SIZE=2^12（4KB），mempages=物理內(nèi)存大小/PAGE_SIZE，對(duì)于256M的內(nèi)存的機(jī)器，mempages=256*2^20/2^12=256*2^8，此時(shí)最大線程數(shù)為4096。
?
但為了保證每個(gè)用戶（除了root）的進(jìn)程總數(shù)不至于占用一半以上物理內(nèi)存，fork_init()中繼續(xù)指定：
?
init_task.rlim[RLIMIT_NPROC].rlim_cur = max_threads/2; init_task.rlim[RLIMIT_NPROC].rlim_max = max_threads/2;?
這些進(jìn)程數(shù)目的檢查都在do_fork()中進(jìn)行，因此，對(duì)于LinuxThreads來說，線程總數(shù)同時(shí)受這三個(gè)因素的限制。
?
4)管理線程問題
?
管理線程容易成為瓶頸，這是這種結(jié)構(gòu)的通病；同時(shí)，管理線程又負(fù)責(zé)用戶線程的清理工作，因此，盡管管理線程已經(jīng)屏蔽了大部分的信號(hào)，但一旦管理線程死亡，用戶線程就不得不手工清理了，而且用戶線程并不知道管理線程的狀態(tài)，之后的線程創(chuàng)建等請(qǐng)求將無人處理。
?
5)同步問題
?
LinuxThreads中的線程同步很大程度上是建立在信號(hào)基礎(chǔ)上的，這種通過內(nèi)核復(fù)雜的信號(hào)處理機(jī)制的同步方式，效率一直是個(gè)問題。
?
6）其他POSIX兼容性問題
?
Linux中很多系統(tǒng)調(diào)用，按照語義都是與進(jìn)程相關(guān)的，比如nice、setuid、setrlimit等，在目前的LinuxThreads中，這些調(diào)用都僅僅影響調(diào)用者線程。
?
7）實(shí)時(shí)性問題
?
線程的引入有一定的實(shí)時(shí)性考慮，但LinuxThreads暫時(shí)不支持，比如調(diào)度選項(xiàng)，目前還沒有實(shí)現(xiàn)。不僅LinuxThreads如此，標(biāo)準(zhǔn)的Linux在實(shí)時(shí)性上考慮都很少。
?
四.其他的線程實(shí)現(xiàn)機(jī)制
?
LinuxThreads的問題，特別是兼容性上的問題，嚴(yán)重阻礙了Linux上的跨平臺(tái)應(yīng)用（如Apache）采用多線程設(shè)計(jì)，從而使得Linux上的線程應(yīng)用一直保持在比較低的水平。在Linux社區(qū)中，已經(jīng)有很多人在為改進(jìn)線程性能而努力，其中既包括用戶級(jí)線程庫(kù)，也包括核心級(jí)和用戶級(jí)配合改進(jìn)的線程庫(kù)。目前最為人看好的有兩個(gè)項(xiàng)目，一個(gè)是RedHat公司牽頭研發(fā)的NPTL（Native Posix Thread Library），另一個(gè)則是IBM投資開發(fā)的NGPT（Next Generation Posix Threading），二者都是圍繞完全兼容POSIX 1003.1c，同時(shí)在核內(nèi)和核外做工作以而實(shí)現(xiàn)多對(duì)多線程模型。這兩種模型都在一定程度上彌補(bǔ)了LinuxThreads的缺點(diǎn)，且都是重起爐灶全新設(shè)計(jì)的。
?
1.NPTL
?
NPTL的設(shè)計(jì)目標(biāo)歸納可歸納為以下幾點(diǎn)：
?
- POSIX兼容性
- SMP結(jié)構(gòu)的利用
- 低啟動(dòng)開銷
- 低鏈接開銷（即不使用線程的程序不應(yīng)當(dāng)受線程庫(kù)的影響）
- 與LinuxThreads應(yīng)用的二進(jìn)制兼容性
- 軟硬件的可擴(kuò)展能力
- 多體系結(jié)構(gòu)支持
- NUMA支持
- 與C++集成
?
在技術(shù)實(shí)現(xiàn)上，NPTL仍然采用1:1的線程模型，并配合glibc和最新的Linux Kernel2.5.x開發(fā)版在信號(hào)處理、線程同步、存儲(chǔ)管理等多方面進(jìn)行了優(yōu)化。和LinuxThreads不同，NPTL沒有使用管理線程，核心線程的管理直接放在核內(nèi)進(jìn)行，這也帶了性能的優(yōu)化。
?
主要是因?yàn)楹诵牡膯栴}，NPTL仍然不是100%POSIX兼容的，但就性能而言相對(duì)LinuxThreads已經(jīng)有很大程度上的改進(jìn)了。
?
2.NGPT
?
IBM的開放源碼項(xiàng)目NGPT在2003年1月10日推出了穩(wěn)定的2.2.0版，但相關(guān)的文檔工作還差很多。就目前所知，NGPT是基于GNU Pth（GNU Portable Threads）項(xiàng)目而實(shí)現(xiàn)的M:N模型，而GNU Pth是一個(gè)經(jīng)典的用戶級(jí)線程庫(kù)實(shí)現(xiàn)。
?
按照2003年3月NGPT官方網(wǎng)站上的通知，NGPT考慮到NPTL日益廣泛地為人所接受，為避免不同的線程庫(kù)版本引起的混亂，今后將不再進(jìn)行進(jìn)一步開發(fā)，而今進(jìn)行支持性的維護(hù)工作。也就是說，NGPT已經(jīng)放棄與NPTL競(jìng)爭(zhēng)下一代Linux POSIX線程庫(kù)標(biāo)準(zhǔn)。
?
3.其他高效線程機(jī)制
?
此處不能不提到Scheduler Activations。這個(gè)1991年在ACM上發(fā)表的多線程內(nèi)核結(jié)構(gòu)影響了很多多線程內(nèi)核的設(shè)計(jì)，其中包括Mach3.0、NetBSD和商業(yè)版本Digital Unix（現(xiàn)在叫Compaq True64 Unix）。它的實(shí)質(zhì)是在使用用戶級(jí)線程調(diào)度的同時(shí)，盡可能地減少用戶級(jí)對(duì)核心的系統(tǒng)調(diào)用請(qǐng)求，而后者往往是運(yùn)行開銷的重要來源。采用這種結(jié)構(gòu)的線程機(jī)制，實(shí)際上是結(jié)合了用戶級(jí)線程的靈活高效和核心級(jí)線程的實(shí)用性，因此，包括Linux、FreeBSD在內(nèi)的多個(gè)開放源碼操作系統(tǒng)設(shè)計(jì)社區(qū)都在進(jìn)行相關(guān)研究，力圖在本系統(tǒng)中實(shí)現(xiàn)Scheduler Activations。
?
相關(guān)主題
?
- [Linus Torvalds，2002] Linux內(nèi)核源碼v2.4.20
- [GNU，2002] Glibc源碼v2.2.2（內(nèi)含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官方網(wǎng)站
- [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線程初探
?
轉(zhuǎn)載于:https://www.cnblogs.com/alantu2018/p/8477038.html
總結(jié)
以上是生活随笔為你收集整理的线程模型、pthread 系列函数 和 简单多线程服务器端程序的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 原生Java代码拷贝目录
- 下一篇： linux下mysql无法看到3306端