→ Caesar08: top與iNum有data race喔,麻煩用mutex或atomic之類的 05/17 23:50
→ djshen: 你有跑過嗎 05/18 00:59
→ Zoxge: 有跑過喔 請問哪裡有問題呢? 05/18 08:06
→ Zoxge: 我有用mutex保護 pthread_mutex_lock( &mutex1 ); 05/18 08:07
→ Zoxge: 請問會有race的原因是哪裡呢? 05/18 08:07
推 cphe: 看起來怪怪的,你的semaphore 定為1000和0就已經定義了buffe 05/18 13:48
→ cphe: r的上下限,為何還要各自一個迴圈做判斷是否為空或滿 05/18 13:48
→ cphe: 一樓指的是你mutex外面有用到shared variable沒包到,你取 05/18 13:55
→ cphe: 到的值有可能不正確 05/18 13:55
※ 編輯: Zoxge (123.192.95.44), 05/18/2018 22:35:25
→ Zoxge: 感謝提醒,我沒弄清楚semaphore的用法,那迴圈的確是多餘的 05/18 22:36
→ Zoxge: 另外小弟想到一個問題,當consumer超過一個 (上面new code) 05/18 22:37
→ Zoxge: 有可能發生多個consumer同時等到 sem_wait( &full ); 成立 05/18 22:38
→ Zoxge: 但其實Buffer內資源不足的情況 05/18 22:38
→ Zoxge: 例如producer已經停止產生新資源,而Buffer內只剩1個資源, 05/18 22:39
※ 編輯: Zoxge (123.192.95.44), 05/18/2018 22:43:08
→ Zoxge: 那就只會有一個consumer能夠跑完,其餘的consumer只能永遠 05/18 22:43
→ Zoxge: 卡在等 sem_wait( &full ); 成立,這樣code就跑不完了 @@ 05/18 22:44
→ Zoxge: 這種問題該怎麼解決呢? 05/18 22:44
→ Caesar08: semaphore本來就設計成這樣,所以卡住很正常 05/19 12:16
→ Caesar08: 要解決這問題,你可以 05/19 12:19
→ Caesar08: 1.自行做semamphore,專門為這種狀況處理 05/19 12:19
→ Caesar08: 2.不要用semaphore,改成用mutex,做non-block的query, 05/19 12:19
→ Caesar08: 不過如果想要持續等待,就要自己spin 05/19 12:19