Linux多線程編程講解之系列三

多線程系列文章源碼頭文件內容:

#include<pthreaad.h>

#include<unistd.h>

#include<stdio.h>

作為程序員,就是要減少重復勞動,拒絕一切無目的的DIY。哪怕只有三行代碼,哈哈??

上一篇文章?最后我們提到了高效的同步機制,本篇文章來個大亂燉,每個同步機制后續會專門再分享。

互斥鎖

盡管在Posix Thread中同樣可以使用IPC的信號量機制來實現互斥鎖mutex功能,但顯然semphore的功能過于強大了,在Posix Thread中定義了另外一套專門用于線程同步的mutex函數。

1. 創建和銷毀

有兩種方法創建互斥鎖,靜態方式和動態方式。POSIX定義了一個宏PTHREAD_MUTEX_INITIALIZER來靜態初始化互斥鎖,方法如下:?

pthread_mutex_t mutex=PTHREAD_MUTEX_INITIALIZER;?

在LinuxThreads實現中,pthread_mutex_t是一個結構,而PTHREAD_MUTEX_INITIALIZER則是一個結構常量。

動態方式是采用pthread_mutex_init()函數來初始化互斥鎖,API定義如下:?

int pthread_mutex_init(pthread_mutex_t *mutex, const pthread_mutexattr_t *mutexattr)?

其中mutexattr用于指定互斥鎖屬性(見下),如果為NULL則使用缺省屬性。

pthread_mutex_destroy()用于注銷一個互斥鎖,API定義如下:?

int pthread_mutex_destroy(pthread_mutex_t *mutex)?

銷毀一個互斥鎖即意味著釋放它所占用的資源,且要求鎖當前處于開放狀態。由于在Linux中,互斥鎖并不占用任何資源,因此LinuxThreads中的pthread_mutex_destroy()除了檢查鎖狀態以外(鎖定狀態則返回EBUSY)沒有其他動作。

2. 互斥鎖屬性

互斥鎖的屬性在創建鎖的時候指定,在LinuxThreads實現中僅有一個鎖類型屬性,不同的鎖類型在試圖對一個已經被鎖定的互斥鎖加鎖時表現不同。

當前(glibc2.2.3,linuxthreads0.9)有四個值可供選擇:

PTHREAD_MUTEX_TIMED_NP,這是缺省值,也就是普通鎖。當一個線程加鎖以后,其余請求鎖的線程將形成一個等待隊列,并在解鎖后按優先級獲得鎖。這種鎖策略保證了資源分配的公平性。

PTHREAD_MUTEX_RECURSIVE_NP,嵌套鎖,允許同一個線程對同一個鎖成功獲得多次,并通過多次unlock解鎖。如果是不同線程請求,則在加鎖線程解鎖時重新競爭。

PTHREAD_MUTEX_ERRORCHECK_NP,檢錯鎖,如果同一個線程請求同一個鎖,則返回EDEADLK,否則與PTHREAD_MUTEX_TIMED_NP類型動作相同。這樣就保證當不允許多次加鎖時不會出現最簡單情況下的死鎖。

PTHREAD_MUTEX_ADAPTIVE_NP,適應鎖,動作最簡單的鎖類型,僅等待解鎖后重新競爭。

3. 鎖操作

鎖操作主要包括加鎖pthread_mutex_lock()、解鎖pthread_mutex_unlock()和測試加鎖pthread_mutex_trylock()三個,不論哪種類型的鎖,都不可能被兩個不同的線程同時得到,而必須等待解鎖。對于普通鎖和適應鎖類型,解鎖者可以是同進程內任何線程;而檢錯鎖則必須由加鎖者解鎖才有效,否則返回EPERM;對于嵌套鎖,文檔和實現要求必須由加鎖者解鎖,但實驗結果表明并沒有這種限制,這個不同目前還沒有得到解釋。在同一進程中的線程,如果加鎖后沒有解鎖,則任何其他線程都無法再獲得鎖。

int?pthread_mutex_lock(pthread_mutex_t?*mutex)??

int?pthread_mutex_unlock(pthread_mutex_t?*mutex)??

int?pthread_mutex_trylock(pthread_mutex_t?*mutex)?

pthread_mutex_trylock()語義與pthread_mutex_lock()類似,不同的是在鎖已經被占據時返回EBUSY而不是讓出CPU,掛起等待。

4. 其他

POSIX線程鎖機制的Linux實現都不是取消點,因此,延遲取消類型的線程不會因收到取消信號而離開加鎖等待。值得注意的是,如果線程在加鎖后解鎖前被取消,鎖將永遠保持鎖定狀態,因此如果在關鍵區段內有取消點存在,或者設置了異步取消類型,則必須在退出回調函數中解鎖。

這個鎖機制同時也不是異步信號安全的,也就是說,不應該在信號處理過程中使用互斥鎖,否則容易造成死鎖。

條件變量

條件變量是利用線程間共享的全局變量進行同步的一種機制,主要包括兩個動作:一個線程等待"條件變量的條件成立"而掛起;另一個線程使"條件成立"(給出條件成立信號)。為了防止競爭,條件變量的使用總是和一個互斥鎖結合在一起。

1. 創建和注銷

條件變量和互斥鎖一樣,都有靜態動態兩種創建方式,靜態方式使用PTHREAD_COND_INITIALIZER常量,如下:

pthread_cond_t?cond=PTHREAD_COND_INITIALIZER??

動態方式調用pthread_cond_init()函數,API定義如下:?

int?pthread_cond_init(pthread_cond_t?*cond,?pthread_condattr_t?*cond_attr)??

盡管POSIX標準中為條件變量定義了屬性,但在LinuxThreads中沒有實現,因此cond_attr值通常為NULL,且被忽略。

注銷一個條件變量需要調用pthread_cond_destroy(),只有在沒有線程在該條件變量上等待的時候才能注銷這個條件變量,否則返回EBUSY。因為Linux實現的條件變量沒有分配什么資源,所以注銷動作只包括檢查是否有等待線程。API定義如下:

int pthread_cond_destroy(pthread_cond_t *cond)

2. 條件等待和激發

int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex)

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

等待條件有兩種方式:

無條件等待pthread_cond_wait()和計時等待pthread_cond_timedwait(),其中計時等待方式如果在給定時刻前條件沒有滿足,則返回ETIMEOUT,結束等待,其中abstime以與time()系統調用相同意義的絕對時間形式出現,0表示格林尼治時間1970年1月1日0時0分0秒。

無論哪種等待方式,都必須和一個互斥鎖配合,以防止多個線程同時請求pthread_cond_wait()(或pthread_cond_timedwait(),下同)的競爭條件(Race Condition)。mutex互斥鎖必須是普通鎖(PTHREAD_MUTEX_TIMED_NP)或者適應鎖(PTHREAD_MUTEX_ADAPTIVE_NP),且在調用pthread_cond_wait()前必須由本線程加鎖(pthread_mutex_lock()),而在更新條件等待隊列以前,mutex保持鎖定狀態,并在線程掛起進入等待前解鎖。在條件滿足從而離開pthread_cond_wait()之前,mutex將被重新加鎖,以與進入pthread_cond_wait()前的加鎖動作對應。

激發條件有兩種形式,pthread_cond_signal()激活一個等待該條件的線程,存在多個等待線程時按入隊順序激活其中一個;而pthread_cond_broadcast()則激活所有等待線程。

3. 其他

pthread_cond_wait()和pthread_cond_timedwait()都被實現為取消點,因此,在該處等待的線程將立即重新運行,在重新鎖定mutex后離開pthread_cond_wait(),然后執行取消動作。也就是說如果pthread_cond_wait()被取消,mutex是保持鎖定狀態的,因而需要定義退出回調函數來為其解鎖。

以下示例集中演示了互斥鎖和條件變量的結合使用,以及取消對于條件等待動作的影響。在例子中,有兩個線程被啟動,并等待同一個條件變量,如果不使用退出回調函數(見范例中的注釋部分),則tid2將在pthread_mutex_lock()處永久等待。如果使用回調函數,則tid2的條件等待及主線程的條件激發都能正常工作。

pthread_mutex_t mutex;

pthread_cond_t? cond;

void * child1(void *arg)

{

????????pthread_cleanup_push(pthread_mutex_unlock,&mutex);? /* comment 1 */

????????while(1){

????????????????printf("thread 1 get running \n");

????????printf("thread 1 pthread_mutex_lock returns %d\n",

pthread_mutex_lock(&mutex));

????????pthread_cond_wait(&cond,&mutex);

????????????????????printf("thread 1 condition applied\n");

????????pthread_mutex_unlock(&mutex);

????????????????????sleep(5);

????}

????????pthread_cleanup_pop(0);???? /* comment 2 */

}

void *child2(void *arg)

{

????????while(1){

????????????????sleep(3);?????????????? /* comment 3 */

????????????????printf("thread 2 get running.\n");

????????printf("thread 2 pthread_mutex_lock returns %d\n",

pthread_mutex_lock(&mutex));

????????pthread_cond_wait(&cond,&mutex);

????????printf("thread 2 condition applied\n");

????????pthread_mutex_unlock(&mutex);

????????sleep(1);

????????}

}

int main(void)

{

????????int tid1,tid2;

????????printf("hello, condition variable test\n");

????????pthread_mutex_init(&mutex,NULL);

????????pthread_cond_init(&cond,NULL);

????????pthread_create(&tid1,NULL,child1,NULL);

????????pthread_create(&tid2,NULL,child2,NULL);

????????do{

????????sleep(2);?????????????????? /* comment 4 */

????????????????pthread_cancel(tid1);?????? /* comment 5 */

????????????????sleep(2);?????????????????? /* comment 6 */

????????pthread_cond_signal(&cond);

????}while(1);?

????????sleep(100);

????????pthread_exit(0);

}

如果不做注釋5的pthread_cancel()動作,即使沒有那些sleep()延時操作,child1和child2都能正常工作。注釋3和注釋4的延遲使得child1有時間完成取消動作,從而使child2能在child1退出之后進入請求鎖操作。如果沒有注釋1和注釋2的回調函數定義,系統將掛起在child2請求鎖的地方;而如果同時也不做注釋3和注釋4的延時,child2能在child1完成取消動作以前得到控制,從而順利執行申請鎖的操作,但卻可能掛起在pthread_cond_wait()中,因為其中也有申請mutex的操作。child1函數給出的是標準的條件變量的使用方式:回調函數保護,等待條件前鎖定,pthread_cond_wait()返回后解鎖。

條件變量機制不是異步信號安全的,也就是說,在信號處理函數中調用pthread_cond_signal()或者pthread_cond_broadcast()很可能引起死鎖。

信號燈

信號燈與互斥鎖和條件變量的主要不同在于"燈"的概念,燈亮則意味著資源可用,燈滅則意味著不可用。如果說后兩中同步方式側重于"等待"操作,即資源不可用的話,信號燈機制則側重于點燈,即告知資源可用;沒有等待線程的解鎖或激發條件都是沒有意義的,而沒有等待燈亮的線程的點燈操作則有效,且能保持燈亮狀態。當然,這樣的操作原語也意味著更多的開銷。

信號燈的應用除了燈亮/燈滅這種二元燈以外,也可以采用大于1的燈數,以表示資源數大于1,這時可以稱之為多元燈。

1. 創建和注銷

POSIX信號燈標準定義了有名信號燈和無名信號燈兩種,但LinuxThreads的實現僅有無名燈,同時有名燈除了總是可用于多進程之間以外,在使用上與無名燈并沒有很大的區別,因此下面僅就無名燈進行討論。

int sem_init(sem_t *sem, int pshared, unsigned int value)

這是創建信號燈的API,其中value為信號燈的初值,pshared表示是否為多進程共享而不僅僅是用于一個進程。LinuxThreads沒有實現多進程共享信號燈,因此所有非0值的pshared輸入都將使sem_init()返回-1,且置errno為ENOSYS。初始化好的信號燈由sem變量表征,用于以下點燈、滅燈操作。

int sem_destroy(sem_t * sem)

被注銷的信號燈sem要求已沒有線程在等待該信號燈,否則返回-1,且置errno為EBUSY。除此之外,LinuxThreads的信號燈注銷函數不做其他動作。

2. 點燈和滅燈

int sem_post(sem_t * sem)

點燈操作將信號燈值原子地加1,表示增加一個可訪問的資源。

int sem_wait(sem_t * sem)

int sem_trywait(sem_t * sem)

sem_wait()為等待燈亮操作,等待燈亮(信號燈值大于0),然后將信號燈原子地減1,并返回。sem_trywait()為sem_wait()的非阻塞版,如果信號燈計數大于0,則原子地減1并返回0,否則立即返回-1,errno置為EAGAIN。

3. 獲取燈值

int sem_getvalue(sem_t * sem, int * sval)

讀取sem中的燈計數,存于*sval中,并返回0。

4. 其他

sem_wait()被實現為取消點,而且在支持原子"比較且交換"指令的體系結構上,sem_post()是唯一能用于異步信號處理函數的POSIX異步信號安全的API。

異步信號

由于LinuxThreads是在核外使用核內輕量級進程實現的線程,所以基于內核的異步信號操作對于線程也是有效的。但同時,由于異步信號總是實際發往某個進程,所以無法實現POSIX標準所要求的"信號到達某個進程,然后再由該進程將信號分發到所有沒有阻塞該信號的線程中"原語,而是只能影響到其中一個線程。

POSIX異步信號同時也是一個標準C庫提供的功能,主要包括信號集管理(sigemptyset()、sigfillset()、sigaddset()、sigdelset()、sigismember()等)、信號處理函數安裝(sigaction())、信號阻塞控制(sigprocmask())、被阻塞信號查詢(sigpending())、信號等待(sigsuspend())等,它們與發送信號的kill()等函數配合就能實現進程間異步信號功能。LinuxThreads圍繞線程封裝了sigaction()何raise(),本節集中討論LinuxThreads中擴展的異步信號函數,包括pthread_sigmask()、pthread_kill()和sigwait()三個函數。毫無疑問,所有POSIX異步信號函數對于線程都是可用的。

int pthread_sigmask(int how, const sigset_t *newmask, sigset_t *oldmask)

設置線程的信號屏蔽碼,語義與sigprocmask()相同,但對不允許屏蔽的Cancel信號和不允許響應的Restart信號進行了保護。被屏蔽的信號保存在信號隊列中,可由sigpending()函數取出。

int pthread_kill(pthread_t thread, int signo)

向thread號線程發送signo信號。實現中在通過thread線程號定位到對應進程號以后使用kill()系統調用完成發送。

int sigwait(const sigset_t *set, int *sig)

掛起線程,等待set中指定的信號之一到達,并將到達的信號存入*sig中。POSIX標準建議在調用sigwait()等待信號以前,進程中所有線程都應屏蔽該信號,以保證僅有sigwait()的調用者獲得該信號,因此,對于需要等待同步的異步信號,總是應該在創建任何線程以前調用pthread_sigmask()屏蔽該信號的處理。而且,調用sigwait()期間,原來附接在該信號上的信號處理函數不會被調用。

如果在等待期間接收到Cancel信號,則立即退出等待,也就是說sigwait()被實現為取消點。

其他同步方式

除了上述討論的同步方式以外,其他很多進程間通信手段對于LinuxThreads也是可用的,比如基于文件系統的IPC(管道、Unix域Socket等)、消息隊列(Sys.V或者Posix的)、System V的信號燈等。只有一點需要注意,LinuxThreads在核內是作為共享存儲區、共享文件系統屬性、共享信號處理、共享文件描述符的獨立進程看待的。

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,818評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,185評論 3 414
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,656評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,647評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,446評論 6 405
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 54,951評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,041評論 3 440
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,189評論 0 287
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,718評論 1 333
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,602評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,800評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,316評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,045評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,419評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,671評論 1 281
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,420評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,755評論 2 371

推薦閱讀更多精彩內容

  • 轉自:Youtherhttps://www.cnblogs.com/youtherhome/archive/201...
    njukay閱讀 1,621評論 0 52
  • linux線程同步 信號燈:與互斥鎖和條件變量的主要不同在于"燈"的概念,燈亮則意味著資源可用,燈滅則意味著不可用...
    鮑陳飛閱讀 693評論 0 2
  • 簡介 線程創建 線程屬性設置 線程參數傳遞 線程優先級 線程的數據處理 線程的分離狀態 互斥鎖 信號量 一 線程創...
    第八區閱讀 8,577評論 1 6
  • 線程基礎 線程是進程的一個執行單元,執行一段程序片段,線程共享全局變量;線程的查看可以使用命令或者文件來進行查看;...
    秋風弄影閱讀 745評論 0 0
  • 摘要 線程概念,線程與進程的區別與聯系學會線程控制,線程創建,線程終止,線程等待了解線程分離與線程安全學會線程同步...
    狼之足跡閱讀 473評論 2 3