Posix執行緒程式設計指南(3)-執行緒同步 (轉)
Linux/thread/posix_thread/part3/author1">楊沙洲
2001 年 10 月
這是一個關於Posix執行緒的專欄。作者在闡明概念的基礎上,將向您詳細講述Posix執行緒庫API。本文是第三篇將向您講述執行緒同步。
儘管在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而不是掛起等待。
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的條件等待及主執行緒的條件激發都能正常工作。
#include
如果不做註釋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)
sem_wait()為等待燈亮操作,等待燈亮(訊號燈值大於0),然後將訊號燈原子地減1,並返回。sem_trywait()為sem_wait()的非阻塞版,如果訊號燈計數大於0,則原子地減1並返回0,否則立即返回-1,errno置為EAGAIN。
int sem_trywait(sem_t * sem)
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(管道、域Socket等)、訊息佇列(Sys.V或者Posix的)、System V的訊號燈等。只有一點需要注意,LinuxThreads在核內是作為共享區、共享檔案系統屬性、共享訊號處理、共享檔案描述符的獨立程式看待的。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10752019/viewspace-982098/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- POSIX執行緒程式設計起步(2)-執行緒同步 (轉)執行緒程式設計
- Posix執行緒程式設計指南(4)-執行緒終止 (轉)執行緒程式設計
- Posix執行緒程式設計指南(1)-執行緒建立與取消 (轉)執行緒程式設計
- Posix執行緒程式設計指南(2)-執行緒私有資料 (轉)執行緒程式設計
- Posix執行緒程式設計指南(5)-Misc (轉)執行緒程式設計
- .NET多執行緒程式設計(3):執行緒同步 (轉)執行緒程式設計
- POSIX 執行緒詳解(3) (轉)執行緒
- 執行緒同步(C#程式設計指南)執行緒C#程式設計
- POSIX執行緒程式設計起步(1)-Hello World (轉)執行緒程式設計
- python多執行緒程式設計3: 使用互斥鎖同步執行緒Python執行緒程式設計
- .NET多執行緒程式設計(4):執行緒池和非同步程式設計 (轉)執行緒程式設計非同步
- iOS多執行緒程式設計:執行緒同步總結iOS執行緒程式設計
- POSIX執行緒詳解 (轉)執行緒
- POSIX執行緒詳解(2) (轉)執行緒
- java執行緒程式設計(一):執行緒基礎(轉)Java執行緒程式設計
- C#多執行緒程式設計-基元執行緒同步構造C#執行緒程式設計
- Java多執行緒學習(3)執行緒同步與執行緒通訊Java執行緒
- 多執行緒程式設計(轉)執行緒程式設計
- c#執行緒-執行緒同步C#執行緒
- 執行緒同步及執行緒鎖執行緒
- [短文速讀 -5] 多執行緒程式設計引子:程式、執行緒、執行緒安全執行緒程式設計
- Q:你瞭解非同步程式設計、程式、單執行緒、多執行緒嗎?非同步程式設計執行緒
- java併發程式設計——執行緒同步Java程式設計執行緒
- 併發程式設計之多執行緒執行緒安全程式設計執行緒
- 多執行緒和多執行緒同步執行緒
- 【轉】1.1非同步程式設計:執行緒概述及使用非同步程式設計執行緒
- JAVA多執行緒詳解(3)執行緒同步和鎖Java執行緒
- .NET多執行緒程式設計(1):多工和多執行緒 (轉)執行緒程式設計
- 【多執行緒總結(二)-執行緒安全與執行緒同步】執行緒
- 執行緒同步執行緒
- 程式設計思想之多執行緒與多程式(3):Java 中的多執行緒程式設計執行緒Java
- 使用執行緒池優化多執行緒程式設計執行緒優化程式設計
- 多執行緒------執行緒與程式/執行緒排程/建立執行緒執行緒
- 執行緒3--執行緒安全執行緒
- JavaScript 單執行緒之非同步程式設計JavaScript執行緒非同步程式設計
- Java執行緒:執行緒的同步與鎖Java執行緒
- 多執行緒程式設計執行緒程式設計
- 執行緒程式設計(一)執行緒程式設計