避免頻繁鎖定

我的程序從交換中獲取大量數據。數據被解析成刻度對象。典型的刻度線避免頻繁鎖定

struct Tick 
{ 
    string ID; 
    int bidprice[5]; 
    int askprice[5]; 
    int totalTradedQuantity; 
    int totalTradedVolume; 
    ..... 
    ..... 
}

此刻度線對象發佈到網絡並登錄到文件中。目前我正在鎖定更新記號和發佈。

Parser Part: 
lock(); 
tick update 
unlock(); 

Publisher Part: 
lock(); 
tick publish; 
unlock();

由於數據頻率很高（每秒5000個），我必須爲每個收到的數據進行鎖定。會導致性能問題嗎？我如何避免採取這麼多的鎖。任何人都可以建議一個最小鎖定的設計實現。請幫忙。

來源

2013-07-22 bhavesh

我認爲它需要鎖機制。我沒有看到任何減少它的選項。如果我沒有錯，你在內部使用Mutex鎖定機制。如果是這種情況，請使用try-lock功能。它至少不會阻止線程。 –

「標記更新」和「標記發佈」包含了什麼內容。如果你所做的只是將已經準備好的數據複製到某種列表中，那麼它不會壞。如果涉及很多工作，那麼也許你應該考慮是否可以將某些工作「移出」鎖定，因此只需「將數據複製到列表中」的最後步驟。同樣，對於「滴答發佈」，只有在您從列表中提取數據時才鎖定 - 一旦您擁有分離的數據項，您可以釋放該鎖。 –

該問題沒有足夠的有關更新和發佈過程的信息。它們是否在共享Tick的實例的單獨進程/線程中運行？ –

鎖定或信號燈是防止競爭條件的唯一工具。

信號將阻止繁忙的等待。但鎖（特別是自旋鎖）將導致繁忙的等待。（在你的情況下，數據頻率高，你不應該擔心忙等待）。

但是，有非常有效和快速的鎖定機制部署到CPU。在這種情況下，您不必擔心鎖定和解鎖開銷。

此外，您始終可以選擇將請求排隊並將它們處理爲解鎖部分鎖&。

來源

2013-07-22 17:35:55 sgun

你在說哪個操作系統的信號量在哪裏等待 - 我所知道的四個（Linux（以及其他類型的Unix），Windows，OSE和Symbian）做了適當的「讓這個線程/進程等到信號量自由」。只有螺旋鎖忙於等待這些操作系統的任何一個。 –

我指的是脫螺旋課程。 – sgun

因爲你需要互斥，所以你需要鎖定。你目前的設計可以做的最好的事情就是使用不同尋常的鎖。例如，如果您閱讀的內容比編寫的內容多，則可以使用讀寫器鎖定。如果線程之間幾乎沒有爭用，並且同一個線程通常會連續多次需要該鎖，則可能會因偏置鎖而獲得性能提升。

但是，我懷疑你更好的選擇是重新設計。我最喜歡的書是Is Parallel Programming Hard, and, If So, What Can You Do About It?。我讀過的每一本其他並行編程書籍都展示瞭如何使線程通信（例如通過鎖）。本書展示瞭如何進行設計，以便線程可以獨立運行而無需進行通信（尤其是無需通過鎖定進行協調）。

來源

2013-07-22 17:56:53

取鎖並不差。鎖爭用不好。你有多少把鎖？每個標記一個，每個標記一個，總共一個？通常最簡單的解決方案是避免單一集中鎖。

來源

2013-07-23 23:53:55 MSalters

避免頻繁鎖定

回答

相關問題