問個多線程方面的問題。

dinghwy

最近寫一個程序，這個程序里面有個操作需要先begin 然后進行一些處理，后面調(diào)用end結束操作。
但是begin和end不能嵌套。
現(xiàn)在問題是，多線程的每個函數(shù)都要進行begin和end操作。但是還沒想好一個方法能避免在兩個線程里面同時調(diào)用begin和end的操作。
程序經(jīng)常就稀里糊涂的就崩潰了。但是有時候會好好的工作上半天。
看看大家有什么好辦法！

@sky

上鎖啊

anthony1983

汗一個

dinghwy

上鎖我知道。但是那樣會導致程序慢的跟爬似的。

anthony1983

原帖由 dinghwy 于 2008-3-30 14:03 發(fā)表
上鎖我知道。但是那樣會導致程序慢的跟爬似的。

多線程編程的臨界區(qū)保護，不用鎖還用什么？ 還有比鎖更加快的調(diào)度么？

不然就自己用管道模擬一個鎖

創(chuàng)建管道

寫入一個字節(jié)數(shù)據(jù)


線程主函數(shù){

revc阻塞讀取管道中的數(shù)據(jù)
臨界區(qū)
send一個字節(jié)到管道中去


}


這樣就能保證子線程們只有一個線程在執(zhí)行臨界區(qū)代碼了


這是土辦法~~~

不清楚你的程序的需求，也不好妄加評價~~

dinghwy

原帖由 anthony1983 于 2008-3-30 14:13 發(fā)表

多線程編程的臨界區(qū)保護，不用鎖還用什么？ 還有比鎖更加快的調(diào)度么？

不然就自己用管道模擬一個鎖

創(chuàng)建管道

寫入一個字節(jié)數(shù)據(jù)


線程主函數(shù){

revc阻塞讀取管道中的數(shù)據(jù)
臨界區(qū)
send一個字節(jié) ...

begin和end是對屏幕顯示緩沖區(qū)進行讀寫操作的開始和結束標志。
如果加鎖，原來每70毫秒就要更新一次屏幕信息的函數(shù)就會使整個界面非常的卡。并且隨時都有新的顯示更新函數(shù)要調(diào)用。 加鎖的話，導致程序變得非常的卡。這個程序原本是windows的，但是移植后，程序的架構已經(jīng)不太適合現(xiàn)在的系統(tǒng)了。又不能改。主要是windows跟MAC的圖形顯示系統(tǒng)不太一樣。
加鎖是我最后的解決方法。

anthony1983

原帖由 dinghwy 于 2008-3-30 14:27 發(fā)表

begin和end是對屏幕顯示緩沖區(qū)進行讀寫操作的開始和結束標志。
如果加鎖，原來每70毫秒就要更新一次屏幕信息的函數(shù)就會使整個界面非常的卡。并且隨時都有新的顯示更新函數(shù)要調(diào)用。 加鎖的話，導致程序變得非 ...

LZ玩得傲啊·~~~WIN-->MAC了都，我還在命令行下敲 。。。

為什么加鎖會導致慢呢？ 難道單個線程占用鎖的時間過長？

如果加鎖操作占用臨界區(qū)的操作時間過長的話，那么是否可以考慮將任務分割呢？

[ 本帖最后由 anthony1983 于 2008-3-30 14:37 編輯 ]

cugb_cat

可以考慮將非線程安全部分縮小，只有在非加鎖不可的時候再加。

apollolegend

原帖由 cugb_cat 于 2008-3-30 20:04 發(fā)表
可以考慮將非線程安全部分縮小，只有在非加鎖不可的時候再加。

確實要控制好鎖的粒度，不然多線程的效率就會比較低了。opengl之類的東西不是有雙緩存么，難道你多個線程同時訪問顯示緩存，我覺得像顯示緩存這樣的資源還是使用管程機制比較好，讓每個請求寫屏的線程排隊等吧

dinghwy

原帖由 apollolegend 于 2008-3-30 20:57 發(fā)表

確實要控制好鎖的粒度，不然多線程的效率就會比較低了。opengl之類的東西不是有雙緩存么，難道你多個線程同時訪問顯示緩存，我覺得像顯示緩存這樣的資源還是使用管程機制比較好，讓每個請求寫屏的線程排隊等吧

我也在懷疑粒度可能太細了。導致大部分時間都在加鎖解鎖。實際的寫屏操作太少。
給人的感覺就是移植程序比自己寫程序都累。每個平臺不同的特性實在不好把握。