2012-01-20 15 views
2

我在Linux上使用pthread。我有一個循環緩衝區來將數據從一個線程傳遞到另一個線程。也許循環緩衝區不是最好的結構在這裏使用,但改變這不會讓我的問題消失,所以我們只是將它作爲一個隊列。在線程爭用下等待最快的方法

無論我的隊列是滿還是空,pop/push操作都會返回NULL。這是有問題的,因爲我的線程週期性地啓動。等待另一個線程循環將花費太長時間。

我試過使用信號量(sem_post,sem_wait),但在爭用下解鎖需要25毫秒,這是關於我的循環速度。我試過用pthread_cond_t等待,但解鎖需要10到15毫秒。

有沒有更快的機制可以用來等待數據?

編輯*

好吧,我使用條件變量。我在嵌入式設備上,因此添加「更多核心或CPU功率」不是一種選擇。這讓我意識到我有各種各樣的線程優先級設置在所有的地方,所以我會在進一步深入之前對此進行排序

+2

你必須要麼可怕地濫用這些同步功能,要麼可怕地錯誤地測量他們的行爲以找到這些時間。條件變量大概是你可以做的最好的,並且它們幾乎是瞬間的。你如何使用它們,可能更重要的是,你如何測量? –

+0

我使用clock_gettime(CLOCK_REALTIME,&time)來測量,在釋放鎖之前和之後 – Eric

+0

您是否偶然在相同的行/函數調用中獲得結束時間,以便您進行I/O記錄? –

回答

4

您應該使用條件變量。唯一更快的方法是特定於平臺的,而且它們的速度可以忽略不計。

你正在看到你認爲糟糕的表現,只是因爲你的線程正在被解除安排。當線程接近其時間片結束時,您會看到很長的「延遲」,並且調度程序允許未阻止的線程預先佔用正在運行的線程。如果你擁有比線程更多的內核,或者將線程設置爲更高的優先級,那麼你將不會看到這些延遲。

但是,這些延誤實際上是一件好事,你不應該關心它們。其他線程也有機會運行。

+1

25ms?這對於一個簡單的鎖定來說非常長... –

+1

時間段與鎖無關。鎖在毫秒的第一部分被釋放。另一次是線程沒有運行的時候,因爲系統正在做其他事情。 –

+0

大衛的+1 - 框被重載。需要更多的核心,(可能更多的RAM),更少的CPU密集型應用程序。對於比利 - 25us也是+1,不用擔心ms,對於鎖定版本來說太長了。 –