[C++] UNIX上C++程序設計守則(5)
準則5: 盡可能避免線程中做延遲撤銷的處理
- 線程的異步撤消是指：一個線程發(fā)出中斷其他線程的處理的一個動作
- 延遲撤消因為是規(guī)格自由度比較高、所以根據(jù)OS和C庫函數(shù)的版本它也有各式各樣的動作
- 要想在不同的環(huán)境下都能穩(wěn)定的動作的話，就必須要詳細調(diào)查運行環(huán)境和，對C庫函數(shù)進行抽象化，做必要的條件編譯
- 在C++中、「撤消發(fā)生時的對象釋放」的實現(xiàn)不具有可移植性
說明:
在前面我們已經(jīng)講過，線程的撤消分為「異步」「延遲」這兩種類型、并且「異步撤消」也是非常容易引起各種復雜問題的元兇。
那么，現(xiàn)在要在程序中除掉「延遲撤消」。延遲撤消雖然不會像異步撤消那樣會引起各種各樣的問題、但是、注意事項還是有很多的。只有把下面的這些注意事項全部都把握之后才能放心使用。
注意事項1: 要好好把握撤消點
和異步撤消不一樣的是、撤消處理一直會被延遲到在代碼上明示出來的撤消點之后才會被執(zhí)行。如果編寫了一個具有延遲撤消可能的代碼、代碼中的那條語句是撤消點、必須要正確的把握。
首先、調(diào)用過pthread_testcancel函數(shù)的地方就變成撤消點了。當然這個函數(shù)是、僅僅為了「變成延遲撤消」的目的而設置出來的函數(shù)。除此之外、某些標準庫函數(shù)被調(diào)用后會不會變成撤消點是在規(guī)格(SUSv3)中決定的。請參照規(guī)格說明、有下面的函數(shù)一覽。
下面的函數(shù)是撤消點
accept, aio_suspend, clock_nanosleep, close, connect, creat, fcntl, fdatasync,
fsync, getmsg, getpmsg, lockf, mq_receive, mq_send, mq_timedreceive,
mq_timedsend, msgrcv, msgsnd, msync, nanosleep, open, pause, poll, pread,
pselect, pthread_cond_timedwait, pthread_cond_wait, pthread_join,
pthread_testcancel, putmsg, putpmsg, pwrite, read, readv, recv, recvfrom,
(略)
下面的函數(shù)不是撤消點
access, asctime, asctime_r, catclose, catgets, catopen, closedir, closelog,
ctermid, ctime, ctime_r, dbm_close, dbm_delete, dbm_fetch, dbm_nextkey, dbm_open,
dbm_store, dlclose, dlopen, endgrent, endhostent, endnetent, endprotoent,
endpwent, endservent, endutxent, fclose, fcntl, fflush, fgetc, fgetpos, fgets,
fgetwc, fgetws, fmtmsg, fopen, fpathconf, fprintf, fputc, fputs, fputwc, fputws,
(略)
看到這些我想已經(jīng)明白了、但是在規(guī)格中也說明了「能否成為撤消點跟具體的實現(xiàn)相關的函數(shù)」也是多數(shù)存在的。原因是、為了可移植性、保證「在一定的時間內(nèi)讓線程的延遲撤消完成」是很困難的事情。做的不好的話、只要稍微一提升OS的版本就可能讓做出來的程序產(chǎn)品不能動作。
即使是這樣那還想要使用延遲撤消嗎？
注意事項2: 實現(xiàn)要知道cleanup函數(shù)的必要性
可能被延遲撤銷的線程在運行的過程中，要申請資源的場合，一定要考慮到以下的幾點，否則就會編制出含有資源丟失和死鎖的軟件產(chǎn)品。
例如編寫的下面的函數(shù)就不能被安全的延遲撤銷掉。
void* cancel_unsafe(void*) {
static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_lock(&mutex); // 此處不是撤消點
struct timespec ts = {3, 0}; nanosleep(&ts, 0); // 經(jīng)常是撤消點
pthread_mutex_unlock(&mutex); // 此處不是撤消點
return 0;
}
int main(void) {
pthread_t t;
// pthread_create后馬發(fā)上收到一個有效的延遲撤消的要求
pthread_create(&t, 0, cancel_unsafe, 0);
pthread_cancel(t);
pthread_join(t, 0);
cancel_unsafe(0); // 發(fā)生死鎖！
return 0;
}
在上面的樣例代碼中、nanosleep執(zhí)行的過程中經(jīng)常會觸發(fā)延遲撤銷的最終動作，但是這個時候的mutex鎖還處于被鎖定的狀態(tài)。而且、線程一被延遲撤消的話就意味著沒有人去釋放掉這個互斥鎖了。因此、在下面的main函數(shù)中調(diào)用同樣的cancel_unsafe函數(shù)時就會引起死鎖了。
為了回避這個問題、利用pthread_cleanup_push函數(shù)在撤消時釋放掉互斥鎖的話就OK了，也就不會死鎖了。
// 新增清除函數(shù)
void cleanup(void* mutex) {
pthread_mutex_unlock((pthread_mutex_t*)mutex);
}
// 粗體字部分是新增的語句
void* cancel_unsafe(void*) {
static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cleanup_push(cleanup, &mutex);
pthread_mutex_lock(&mutex);
struct timespec ts = {3, 0}; nanosleep(&ts, 0);
pthread_mutex_unlock(&mutex);
pthread_cleanup_pop(0);
return 0;
}
注意事項3: 實現(xiàn)要清楚延遲撤消和C++之間的兼容度
使用C語言的場合，利用上面的pthread_cleanup_push/pop函數(shù)就能安全地執(zhí)行延遲撤消的動作，但是在C++語言的場合就會出現(xiàn)其他的問題。C++與延遲撤消之間的兼容度是非常差的。具體的表現(xiàn)有以下兩個問題:
- 執(zhí)行延遲撤消的時候，內(nèi)存棧上的對象的析構函數(shù)會不會被調(diào)用跟具體的開發(fā)環(huán)境有關系
- GCC3版本就不會調(diào)用。
- Solaris和Tru64 UNIX下的原生編譯器的場合，就調(diào)用析構函數(shù)(好像)
- pthread_cleanup_push/pop函數(shù)和C++的異常處理機制之間有著怎樣的相互影響也能具體環(huán)境有關
不調(diào)用析構函數(shù)，或者在拋出異常的時候不能做cleanup處理，經(jīng)常是發(fā)生內(nèi)存泄漏，資源丟失，程序崩潰，死鎖等現(xiàn)象的原因。令人意外的是對于這個深層次的問題，就連Boost C++庫都束手無策。
[Q] Why isn't thread cancellation or termination provided?
[A] There's a valid need for thread termination, so at some point Boost.Threads probably will include it, but only after we can find a truly safe (and portable) mechanism for this concept.
先必須確保對象的自由存儲，而后全都讓cleanup函數(shù)去釋放對象的方法也有，但是這次是犧牲了異常安全性。
（原文沒有看明白：オブジェクトを必ずフリーストア上に確保し、解體を全て、クリーンナップハンドラに行わせる手もありますが、今度は例外安全性が犠牲になるでしょう。）
應該說的是，在使用C++的工程里不對線程進行延遲撤消處理還是比較實際的。