[C++] UNIX上C++程序設(shè)計(jì)守則(5)
準(zhǔn)則5: 盡可能避免線程中做延遲撤銷的處理
- 線程的異步撤消是指：一個(gè)線程發(fā)出中斷其他線程的處理的一個(gè)動(dòng)作
- 延遲撤消因?yàn)槭且?guī)格自由度比較高、所以根據(jù)OS和C庫(kù)函數(shù)的版本它也有各式各樣的動(dòng)作
- 要想在不同的環(huán)境下都能穩(wěn)定的動(dòng)作的話，就必須要詳細(xì)調(diào)查運(yùn)行環(huán)境和，對(duì)C庫(kù)函數(shù)進(jìn)行抽象化，做必要的條件編譯
- 在C++中、「撤消發(fā)生時(shí)的對(duì)象釋放」的實(shí)現(xiàn)不具有可移植性
說(shuō)明:
在前面我們已經(jīng)講過(guò)，線程的撤消分為「異步」「延遲」這兩種類型、并且「異步撤消」也是非常容易引起各種復(fù)雜問(wèn)題的元兇。
那么，現(xiàn)在要在程序中除掉「延遲撤消」。延遲撤消雖然不會(huì)像異步撤消那樣會(huì)引起各種各樣的問(wèn)題、但是、注意事項(xiàng)還是有很多的。只有把下面的這些注意事項(xiàng)全部都把握之后才能放心使用。
注意事項(xiàng)1: 要好好把握撤消點(diǎn)
和異步撤消不一樣的是、撤消處理一直會(huì)被延遲到在代碼上明示出來(lái)的撤消點(diǎn)之后才會(huì)被執(zhí)行。如果編寫了一個(gè)具有延遲撤消可能的代碼、代碼中的那條語(yǔ)句是撤消點(diǎn)、必須要正確的把握。
首先、調(diào)用過(guò)pthread_testcancel函數(shù)的地方就變成撤消點(diǎn)了。當(dāng)然這個(gè)函數(shù)是、僅僅為了「變成延遲撤消」的目的而設(shè)置出來(lái)的函數(shù)。除此之外、某些標(biāo)準(zhǔn)庫(kù)函數(shù)被調(diào)用后會(huì)不會(huì)變成撤消點(diǎn)是在規(guī)格(SUSv3)中決定的。請(qǐng)參照規(guī)格說(shuō)明、有下面的函數(shù)一覽。
下面的函數(shù)是撤消點(diǎn)
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ù)不是撤消點(diǎn)
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ī)格中也說(shuō)明了「能否成為撤消點(diǎn)跟具體的實(shí)現(xiàn)相關(guān)的函數(shù)」也是多數(shù)存在的。原因是、為了可移植性、保證「在一定的時(shí)間內(nèi)讓線程的延遲撤消完成」是很困難的事情。做的不好的話、只要稍微一提升OS的版本就可能讓做出來(lái)的程序產(chǎn)品不能動(dòng)作。
即使是這樣那還想要使用延遲撤消嗎？
注意事項(xiàng)2: 實(shí)現(xiàn)要知道cleanup函數(shù)的必要性
可能被延遲撤銷的線程在運(yùn)行的過(guò)程中，要申請(qǐng)資源的場(chǎng)合，一定要考慮到以下的幾點(diǎn)，否則就會(huì)編制出含有資源丟失和死鎖的軟件產(chǎn)品。
例如編寫的下面的函數(shù)就不能被安全的延遲撤銷掉。
void* cancel_unsafe(void*) {
static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_lock(&mutex); // 此處不是撤消點(diǎn)
struct timespec ts = {3, 0}; nanosleep(&ts, 0); // 經(jīng)常是撤消點(diǎn)
pthread_mutex_unlock(&mutex); // 此處不是撤消點(diǎn)
return 0;
}
int main(void) {
pthread_t t;
// pthread_create后馬發(fā)上收到一個(gè)有效的延遲撤消的要求
pthread_create(&t, 0, cancel_unsafe, 0);
pthread_cancel(t);
pthread_join(t, 0);
cancel_unsafe(0); // 發(fā)生死鎖！
return 0;
}
在上面的樣例代碼中、nanosleep執(zhí)行的過(guò)程中經(jīng)常會(huì)觸發(fā)延遲撤銷的最終動(dòng)作，但是這個(gè)時(shí)候的mutex鎖還處于被鎖定的狀態(tài)。而且、線程一被延遲撤消的話就意味著沒(méi)有人去釋放掉這個(gè)互斥鎖了。因此、在下面的main函數(shù)中調(diào)用同樣的cancel_unsafe函數(shù)時(shí)就會(huì)引起死鎖了。
為了回避這個(gè)問(wèn)題、利用pthread_cleanup_push函數(shù)在撤消時(shí)釋放掉互斥鎖的話就OK了，也就不會(huì)死鎖了。
// 新增清除函數(shù)
void cleanup(void* mutex) {
pthread_mutex_unlock((pthread_mutex_t*)mutex);
}
// 粗體字部分是新增的語(yǔ)句
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;
}
注意事項(xiàng)3: 實(shí)現(xiàn)要清楚延遲撤消和C++之間的兼容度
使用C語(yǔ)言的場(chǎng)合，利用上面的pthread_cleanup_push/pop函數(shù)就能安全地執(zhí)行延遲撤消的動(dòng)作，但是在C++語(yǔ)言的場(chǎng)合就會(huì)出現(xiàn)其他的問(wèn)題。C++與延遲撤消之間的兼容度是非常差的。具體的表現(xiàn)有以下兩個(gè)問(wèn)題:
- 執(zhí)行延遲撤消的時(shí)候，內(nèi)存棧上的對(duì)象的析構(gòu)函數(shù)會(huì)不會(huì)被調(diào)用跟具體的開發(fā)環(huán)境有關(guān)系
- GCC3版本就不會(huì)調(diào)用。
- Solaris和Tru64 UNIX下的原生編譯器的場(chǎng)合，就調(diào)用析構(gòu)函數(shù)(好像)
- pthread_cleanup_push/pop函數(shù)和C++的異常處理機(jī)制之間有著怎樣的相互影響也能具體環(huán)境有關(guān)
不調(diào)用析構(gòu)函數(shù)，或者在拋出異常的時(shí)候不能做cleanup處理，經(jīng)常是發(fā)生內(nèi)存泄漏，資源丟失，程序崩潰，死鎖等現(xiàn)象的原因。令人意外的是對(duì)于這個(gè)深層次的問(wèn)題，就連Boost C++庫(kù)都束手無(wú)策。
[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.
先必須確保對(duì)象的自由存儲(chǔ)，而后全都讓cleanup函數(shù)去釋放對(duì)象的方法也有，但是這次是犧牲了異常安全性。
（原文沒(méi)有看明白：オブジェクトを必ずフリーストア上に確保し、解體を全て、クリーンナップハンドラに行わせる手もありますが、今度は例外安全性が犠牲になるでしょう。）
應(yīng)該說(shuō)的是，在使用C++的工程里不對(duì)線程進(jìn)行延遲撤消處理還是比較實(shí)際的。