青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

陳碩的Blog

用條件變量實現事件等待器的正確與錯誤做法

TL;DR 如果你能一眼看出 https://gist.github.com/chenshuo/6430925 中的那 8 個 Waiter classes 哪些是對的哪些是錯的,本文就不必看了。

前幾天,我發了一條微博 http://weibo.com/1701018393/A7FrW7ZVd ,質疑某本書對 Pthreads 條件變量的封裝是錯的,因為它沒有把 mutex 的 lock()/unlock() 函數暴露出來,導致無法實用。后來大家討論的分歧是這個 cond class 是不是通用的條件變量封裝,還是只是一個特殊的“事件等待器”。作為事件等待器,其實現也是錯的,因為存在丟失事件的可能,可以算是初學者使用條件變量的典型錯誤。

本文的代碼位于 recipes/thread/test/Waiter_test.cc,這里提到的某書的版本相當于 Waiter1 class。

我在拙作《Linux 多線程服務端編程:使用 muduo C++ 網絡庫》第 2.2 節總結了條件變量的使用要點:

條件變量只有一種正確使用的方式,幾乎不可能用錯。對于 wait 端:
1. 必須與 mutex 一起使用,該布爾表達式的讀寫需受此 mutex 保護。
2. 在 mutex 已上鎖的時候才能調用 wait()。
3. 把判斷布爾條件和 wait() 放到 while 循環中。

對于 signal/broadcast 端:
1. 不一定要在 mutex 已上鎖的情況下調用 signal (理論上)。
2. 在 signal 之前一般要修改布爾表達式。
3. 修改布爾表達式通常要用 mutex 保護(至少用作 full memory barrier)。
4. 注意區分 signal 與 broadcast:“broadcast 通常用于表明狀態變化,signal 通常用于表示資源可用。(broadcast should generally be used to indicate state change rather than resource availability。)”

如果用條件變量來實現一個“事件等待器/Waiter”,正確的做法是怎樣的?我的最終答案見 WaiterInMuduo class。“事件等待器”的一種用途是程序啟動時等待初始化完成,也可以直接用 muduo::CountDownLatch 到達相同的目的,將初值設為 1 即可。

以下根據微博上的討論過程給出幾個正確或錯誤的版本,博大家一笑。只要記住 Pthread 的條件變量是邊沿觸發(edge trigger),即 signal()/broadcast() 只會喚醒已經等在 wait() 上的線程(s),我們在編碼時必須要考慮 signal() 早于 wait() 的可能,那么就很容易判斷以下各個版本的正誤了。代碼見 recipes/thread/test/Waiter_test.cc

版本一:錯誤。某書上的原始版,有丟失事件的可能。

1

版本二:錯誤。lock() 之后再 signal(),同樣有丟失事件的可能。

2

版本三:錯誤。引入了 bool signaled_; 條件,但沒有正確處理 spurious wakeup。

版本四五六:正確。僅限 single waiter 使用。

版本七:最佳。可供 multiple waiters 使用。

版本八:錯誤。存在 data race,且有丟失事件的可能。理由見 http://stackoverflow.com/questions/4544234/calling-pthread-cond-signal-without-locking-mutex

總結:使用條件變量,調用 signal() 的時候無法知道是否已經有線程等待在 wait() 上。因此一般總是要先修改“條件”,使其為 true,再調用 signal();這樣 wait 線程先檢查“條件”,只有當條件不成立時才去 wait(),避免了丟事件的可能。換言之,通過使用“條件”,將邊沿觸發(edge trigger)改為電平觸發(level trigger)。這里“修改條件”和“檢查條件”都必須在 mutex 保護下進行,而且這個 mutex 必須用于配合 wait()。

思考題:如果用兩個 mutex,一個用于保護“條件”,另一個專門用于和 cond 配合 wait(),會出現什么情況?

最后注明一點,http://stackoverflow.com/questions/6419117/signal-and-unlock-order 這篇帖子里對 spurious wakeup 的解釋是錯的,spurious wakeup 指的是一次 signal() 調用喚醒兩個或以上 wait()ing 的線程,或者沒有調用 signal() 卻有線程從 wait() 返回。manpage 里對 Pthreads 系列函數的介紹非常到位,值得細讀。

posted on 2013-09-09 03:01 陳碩 閱讀(14279) 評論(21)  編輯 收藏 引用

評論

# re: 用條件變量實現事件等待器的正確與錯誤做法[未登錄] 2013-09-09 11:47 春秋十二月

不錯,假喚醒解釋得對。  回復  更多評論   

# re: 用條件變量實現事件等待器的正確與錯誤做法 2013-09-09 18:31 askforemore1018

"因此一般總是要先修改條件,使其為 true,再調用 signal();這樣 wait 線程先檢查條件,只有當條件不成立時才去 wait(),避免了丟事件的可能"

版本四中, 在 lock、while之后, wait之前,如果有發 signal的話,也會丟失 signal吧  回復  更多評論   

# re: 用條件變量實現事件等待器的正確與錯誤做法 2013-09-09 23:49 陳碩

@askforemore1018
在你說的這種情況下,版本八有可能丟,版本四不可能丟,想想為什么。  回復  更多評論   

# re: 用條件變量實現事件等待器的正確與錯誤做法[未登錄] 2013-09-10 01:02 天道酬勤

對于版本四,只有當signal所在線程先獲得鎖修改條件變量再釋放鎖后,此時wait所在線程獲得鎖正好第一次運行到while處,這時并沒有來得及wait,所以信號丟失了。  回復  更多評論   

# re: 用條件變量實現事件等待器的正確與錯誤做法[未登錄] 2013-09-10 01:06 天道酬勤

@askforemore1018
版本八沒有加鎖,當在 lock、while之后,wait之前,這個時間窗內被切換到signal所在線程時,信號就丟失了。  回復  更多評論   

# re: 用條件變量實現事件等待器的正確與錯誤做法 2013-09-10 01:18 陳碩

@天道酬勤
版本四,在你說的情況下,根本不會去 wait(),因為 while 條件不滿足,因此不會丟信號。  回復  更多評論   

# re: 用條件變量實現事件等待器的正確與錯誤做法 2013-09-10 09:52 天道酬勤

@陳碩
signal不是發出信號了嗎?
  回復  更多評論   

# re: 用條件變量實現事件等待器的正確與錯誤做法 2013-09-10 10:00 陳碩

@ 天道酬勤
你想說啥?  回復  更多評論   

# re: 用條件變量實現事件等待器的正確與錯誤做法[未登錄] 2013-09-10 10:56 andy

class Waiter6 : private WaiterBase
{
public:
void wait()
{
CHECK_SUCCESS(pthread_mutex_lock(&mutex_));
while (!signaled_)
{
CHECK_SUCCESS(pthread_cond_wait(&cond_, &mutex_));
}
CHECK_SUCCESS(pthread_mutex_unlock(&mutex_));
}

void signal()
{
CHECK_SUCCESS(pthread_mutex_lock(&mutex_));
CHECK_SUCCESS(pthread_cond_signal(&cond_));
signaled_ = true;
CHECK_SUCCESS(pthread_mutex_unlock(&mutex_));
}

private:
bool signaled_ = false;
};
有個問題我始終搞不明白,如果一個線程先執行wait() 這樣這個線程在被喚醒前,互斥量一直被加鎖,pthread_mutex_lock(&mutex_)。那么signal(),只有互斥量被unlock了,才能調用pthread_cond_signal(&cond_),那豈不是永遠也喚醒不了wait()線程了?小弟不才,希望有人幫忙解釋下。  回復  更多評論   

# re: 用條件變量實現事件等待器的正確與錯誤做法 2013-09-10 12:45 Rider

@andy
感覺你不知道信號量這個概念,最好能先查下手冊或者翻下OS的書再提問,別人的時間也是時間啊。wait的時候是失去鎖的,并且這一步是原子的。
  回復  更多評論   

# re: 用條件變量實現事件等待器的正確與錯誤做法 2013-09-10 12:47 Rider

@andy
說錯了,是條件變量。  回復  更多評論   

# re: 用條件變量實現事件等待器的正確與錯誤做法 2013-09-10 13:34 slade

弱問版本3 spurious wakeup是怎么解釋的啊,為什么會喚醒多個線程啊  回復  更多評論   

# re: 用條件變量實現事件等待器的正確與錯誤做法[未登錄] 2013-09-10 14:44 joe

@andy
我記得條件變量wait的內部實現是:在所在進場被阻塞前unlock互斥量,這就是為什么wait的參數需要傳入互斥量的原因了
  回復  更多評論   

# re: 用條件變量實現事件等待器的正確與錯誤做法 2013-09-10 15:19 天道酬勤

@陳碩
@天道酬勤
版本四,在你說的情況下,根本不會去 wait(),因為 while 條件不滿足,因此不會丟信號。
但是signal已經被調用,信號不是發出去了嗎?  回復  更多評論   

# re: 用條件變量實現事件等待器的正確與錯誤做法 2013-09-10 15:48 wingc

@ 天道酬勤
這里要處理的情況是是等待線程和信號線程的同步,如果等待函數沒有進入同步區,則說明根本沒有等待線程執行,就算信號線程發出信號但因為沒有等待也就不存在所謂丟失。
這個和版本一不一樣,版本一因為信號函數與等待函數沒有同步,這等待函數有可能在進入一個完全無謂的"同步區"時而沒有開始等待時,信號被另一個線程發出,因此會又信號丟失。
不知道我解釋得對不對,也不知道你理解了沒有?  回復  更多評論   

# re: 用條件變量實現事件等待器的正確與錯誤做法 2013-09-10 17:24 rtemslinux

@andy
phtread_cond_wait的時候,這一個api內部實現有三步
1. unlock
2. wait
3. lock again  回復  更多評論   

# re: 用條件變量實現事件等待器的正確與錯誤做法 2013-09-10 17:27 rtemslinux

@slade

我看wiki說,在多核情況下cond_wait返回,并不代表之前的while條件滿足。
至于pthread_cond_wait為啥會返回,說是
Spurious wakeups may sound strange, but on some multiprocessor systems, making condition wakeup completely predictable might substantially slow all condition variable operations. The race conditions that cause spurious wakeups should be considered rare.  回復  更多評論   

# re: 用條件變量實現事件等待器的正確與錯誤做法 2013-09-11 16:22 tb

畫圖比較易懂些了   回復  更多評論   

# re: 用條件變量實現事件等待器的正確與錯誤做法 2014-04-22 22:26 xanpeng

試解答思考題。
思考題“如果用兩個 mutex,一個用于保護“條件”,另一個專門用于和 cond 配合 wait(),會出現什么情況?”的代碼應該是按下面這么寫。
* mutex_signaled_用來控制對signaled_的訪問,mutex_cond_結合條件變量使用。
* 最大的問題就是原來mutex_unlock+wait是原子的(通過pthread_cond_wait()),現在相當于人為拆分成mutex_unlock,wait兩步。這樣可能丟失事件(unlock和wait之間發生signal)。

class Waiter9 : private WaiterBase
{
public:
void wait()
{
CHECK_SUCCESS(pthread_mutex_lock(&mutex_signaled_));
while (!signaled_)
{
CHECK_SUCCESS(pthread_mutex_unlock(&mutex_signaled_)); // 第一步
CHECK_SUCCESS(pthread_mutex_lock(&mutex_cond_));
CHECK_SUCCESS(pthread_cond_wait(&cond_, &mutex_cond_)); // 第二步
CHECK_SUCCESS(pthread_mutex_unlock(&mutex_cond_));
CHECK_SUCCESS(pthread_mutex_lock(&mutex_signaled_));
}
CHECK_SUCCESS(pthread_mutex_unlock(&mutex_signaled_));
}

void broadcast()
{
CHECK_SUCCESS(pthread_mutex_lock(&mutex_signaled_));
signaled_ = true;
CHECK_SUCCESS(pthread_mutex_unlock(&mutex_signaled_));

CHECK_SUCCESS(pthread_mutex_lock(&mutex_cond_)); // 可以不要
CHECK_SUCCESS(pthread_cond_broadcast(&cond_));
CHECK_SUCCESS(pthread_mutex_unlock(&mutex_cond_));
}

private:
bool signaled_ = false;
};  回復  更多評論   

# re: 用條件變量實現事件等待器的正確與錯誤做法 2015-10-30 09:16 @sunjun

加鎖的情況下,情況4不可能有signal丟失。因為這個waiter在進入之前會獲取mutex鎖,如果條件不滿足cond_wait返回之前會釋放鎖,而在此之前signal是沒有辦法獲取鎖的,也就是說必須要cond_wait釋放鎖之后,signal才有可能執行到@陳碩
  回復  更多評論   

# re: 用條件變量實現事件等待器的正確與錯誤做法 2016-01-01 22:10 dodo

版本三為什么錯誤  回復  更多評論   

<2025年9月>
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

導航

統計

常用鏈接

隨筆分類

隨筆檔案

相冊

搜索

最新評論

閱讀排行榜

評論排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            亚洲电影在线| 欧美在线免费观看| 欧美一区二区黄| 亚洲女女女同性video| 宅男噜噜噜66一区二区 | 亚洲视频在线二区| 国产精品美女久久久久久免费 | 国产精品久久久久久久app| 欧美日韩一区自拍| 国产乱码精品一区二区三| 狠狠色综合色区| 日韩五码在线| 久久久久国产精品一区二区| 久久亚洲精选| 一区二区三区黄色| 欧美综合国产| 欧美日韩国产精品一区| 国产日韩欧美三区| 日韩一级视频免费观看在线| 欧美日韩中文字幕精品| 国产日韩欧美一区二区三区在线观看 | 欧美成人日韩| 日韩亚洲欧美一区| 久久都是精品| 欧美日韩一级黄| 国产曰批免费观看久久久| 亚洲国产高清在线| 欧美专区在线观看一区| 亚洲精品乱码久久久久久久久| 午夜精品亚洲一区二区三区嫩草| 麻豆成人在线播放| 国产精品一区三区| 99亚洲伊人久久精品影院红桃| 国产欧美视频在线观看| 亚洲伦理精品| 欧美不卡一区| 欧美亚洲综合在线| 国产精品大片免费观看| 亚洲肉体裸体xxxx137| 久久久久久香蕉网| 亚洲一区三区在线观看| 欧美精品导航| 亚洲国产一区二区三区高清| 欧美一级片一区| 一区二区高清视频在线观看| 狂野欧美激情性xxxx| 国产日韩欧美电影在线观看| 一区二区三区成人精品| 亚洲国产精彩中文乱码av在线播放| 亚洲欧美在线一区二区| 国产精品青草久久| 亚洲自拍电影| 国产精品99久久久久久白浆小说 | 香港成人在线视频| 一区二区三区高清在线观看| 欧美精品一区二区三区很污很色的| 亚洲精品免费在线观看| 久久久久久久尹人综合网亚洲| 亚洲免费观看| 欧美日韩国产成人在线免费 | 国产欧美精品在线| 亚洲性感美女99在线| 亚洲精品黄网在线观看| 你懂的视频欧美| 亚洲精品在线观| 亚洲精品久久久久久久久| 欧美成人一区二区| 一本色道久久综合一区| 99亚洲一区二区| 欧美三日本三级少妇三99| 在线午夜精品| 亚洲一区二区三区四区中文| 国产精品夜夜嗨| 久久成人免费日本黄色| 欧美一区三区二区在线观看| 国产日韩精品一区二区三区在线| 久久国产精品久久w女人spa| 久久精品99无色码中文字幕| 亚洲成人资源| 99精品国产一区二区青青牛奶| 国产精品久久久久高潮| 久久久水蜜桃| 欧美日韩二区三区| 久久久99久久精品女同性| 六月丁香综合| 亚洲视频在线一区观看| 亚洲一区二区高清视频| 韩国欧美国产1区| 亚洲麻豆一区| 国产专区精品视频| 欧美激情一区在线| 国产精品日韩精品欧美精品| 欧美1区2区3区| 国产精品r级在线| 欧美第十八页| 国产欧美一级| 夜夜嗨av一区二区三区网站四季av| 国产亚洲精品久久久| 亚洲人成在线免费观看| 国产欧美精品在线观看| 亚洲国产精品va在看黑人| 国产亚洲精品久久久久久| 日韩香蕉视频| 亚洲激精日韩激精欧美精品| 亚洲欧美另类久久久精品2019| 亚洲激情电影中文字幕| 性久久久久久| 一区二区三区你懂的| 久久影视精品| 久久久精品tv| 国产精品亚洲а∨天堂免在线| 亚洲另类自拍| 亚洲激情在线视频| 久久成人在线| 欧美在线视频免费观看| 欧美日韩中文在线观看| 亚洲国语精品自产拍在线观看| 黄网动漫久久久| 欧美激情精品久久久久久黑人| 亚洲精品一区二区三区在线观看 | 国产自产精品| 亚洲视频导航| 亚洲视频日本| 欧美激情在线播放| 亚洲承认在线| 亚洲福利国产精品| 久久久青草青青国产亚洲免观| 欧美在线免费观看视频| 国产精品v欧美精品v日本精品动漫 | 欧美不卡视频一区| 免费国产自线拍一欧美视频| 国产日韩欧美在线播放| 午夜精品亚洲| 欧美在线网站| 国产一区二区三区自拍| 亚洲欧美综合网| 欧美在线视频在线播放完整版免费观看 | 美女成人午夜| 在线不卡a资源高清| 久久精品五月婷婷| 欧美成人一区在线| 亚洲精品在线看| 欧美日韩免费观看一区二区三区| 亚洲国产天堂久久国产91| 日韩一级精品| 国产精品日韩一区| 性欧美1819性猛交| 久久综合九色综合欧美狠狠| 揄拍成人国产精品视频| 男女视频一区二区| 一本高清dvd不卡在线观看| 欧美亚洲免费| 在线观看成人一级片| 欧美成人精品三级在线观看| 亚洲欧洲中文日韩久久av乱码| 99精品久久| 国产乱码精品一区二区三| 久久狠狠亚洲综合| 欧美成人综合网站| 亚洲午夜精品久久| 国产综合自拍| 欧美理论在线播放| 亚洲你懂的在线视频| 另类av一区二区| 正在播放欧美一区| 黄色日韩网站视频| 欧美视频导航| 久久男女视频| 一本色道综合亚洲| 乱人伦精品视频在线观看| 一区二区三区国产盗摄| 国产视频观看一区| 欧美电影资源| 欧美亚洲在线播放| 亚洲精品午夜精品| 久久综合色影院| 亚洲欧美精品伊人久久| 欧美国产视频在线观看| 性色av一区二区三区在线观看 | 欧美久久久久免费| 久久精品国产99国产精品澳门| 亚洲黄色影院| 久久综合中文| 亚洲欧美第一页| 亚洲国产精品热久久| 国产精品久久午夜| 欧美成人在线免费观看| 性欧美videos另类喷潮| 亚洲精品一二三| 欧美成人免费一级人片100| 性欧美videos另类喷潮| av成人老司机| 亚洲精华国产欧美| 激情久久久久久久| 国产欧美精品在线| 国产精品一二一区| 国产精品国产a级| 欧美日韩一区二区视频在线| 欧美激情视频在线免费观看 欧美视频免费一| 午夜亚洲福利|