我有一個函數,這是我的應用程序的主要瓶頸,因爲它對線程之間共享的全局列表進行繁重的字符串比較。我的問題基本上是這樣的:多個鎖定在相同的函數
在1函數中多次鎖定列表(稱爲列表gList)是否糟糕。然後稍後再次鎖定(查找時進行基本鎖定,解鎖獲取新項目以準備插入,然後再次鎖定並添加新項目)。
當我你是一個探查器,我沒有看到任何跡象表明,即時付出沉重的代價,但我可以在稍後的時間或當它在野外的代碼?任何人都可以得到最好的體驗或個人經歷?
我有一個函數,這是我的應用程序的主要瓶頸,因爲它對線程之間共享的全局列表進行繁重的字符串比較。我的問題基本上是這樣的:多個鎖定在相同的函數
在1函數中多次鎖定列表(稱爲列表gList)是否糟糕。然後稍後再次鎖定(查找時進行基本鎖定,解鎖獲取新項目以準備插入,然後再次鎖定並添加新項目)。
當我你是一個探查器,我沒有看到任何跡象表明,即時付出沉重的代價,但我可以在稍後的時間或當它在野外的代碼?任何人都可以得到最好的體驗或個人經歷?
這聽起來像你不希望被釋放的查找和插入的鎖。要麼是這樣,要麼在查找過程中不需要鎖定。
只有當元素不在那裏時才試圖添加到列表中嗎?如果是這樣,那麼釋放兩個步驟之間的鎖允許另一個線程在準備元素時添加到列表中。在準備添加時,您的查詢已過時。
如果這不是查詢可能過期的問題,那麼在查找過程中您可能不需要鎖定。
一般而言,您希望鎖定的時間儘可能短。爭用成本要高得多(必須去內核),而非爭用鎖獲取的成本(可以在用戶空間中完成),所以細粒度鎖定通常對性能有好處,即使它意味着獲取鎖定更多次。
也就是說,確保你在適當的情況下進行配置文件:一個具有大量的同時加載。否則,你的結果與現實的關係不大。
在我看來,有幾個數據給出具體的答案。通常,鎖的數量不會造成性能問題,而是等待該鎖的線程數。
你如何執行鎖定?如果還不是這種情況,你可能需要考慮使用ReaderWriterLockSlim
。
下面是一個簡單的使用例子:
class SomeData
{
private IList<string> _someStrings = new List<string>();
private ReaderWriterLockSlim _lock = new ReaderWriterLockSlim();
public void Add(string text)
{
_lock.EnterWriteLock();
try
{
_someStrings.Add(text);
}
finally
{
_lock.ExitWriteLock();
}
}
public bool Contains(string text)
{
_lock.EnterReadLock();
try
{
return _someStrings.Contains(text);
}
finally
{
_lock.ExitReadLock();
}
}
}
除非實際更改列表,否則絕對只能將其鎖定爲讀取權限 – jjxtra 2009-06-19 21:58:10
您是否還在更改和刪除列表中的項目? – BlackTigerX 2009-06-19 21:47:06