QueueUserWorkItem是否鎖定正確實現？

我已經實現了測井方法如下：QueueUserWorkItem是否鎖定正確實現？

ThreadPool.QueueUserWorkItem((state) => { 
    lock (appendLock) { 
     using (StreamWriter log = File.AppendText(_logFile)) { 
      log.WriteLine(message); 
     } 
    } 
}, null);

1：是必需的lock？我想要對日誌進行編程並發現鎖已經存在。因此，我不是簡單地修改那些代碼，而是將其包裝到工作人員代表中。

2：假定鎖是必需的：這是正確的實現入隊包含鎖的委託嗎？多線程可能請求日誌寫入的潛力相當高。通過將委託排隊到工作線程，文件I/O執行的長度不應該影響應用程序本身。

3：假設有幾個logWriteDelegate工人已經入隊：是否會按照的順序調用代表？即現在服務＃32 ...現在服務＃33

來源

2012-07-28 IAbstract

1：是的，鎖定它是必需的。它可以被多個線程訪問，尤其是在您使用該池的情況下。

2：好吧，它會工作。但它會保持文件鎖定，難以閱讀。有一些預先存在的日誌框架在這個問題上做了很多工作 - 可能值得使用它們。

3：no;與鎖和游泳池，這是兩個單獨的原因，不期望在最終文件嚴格排序。事實上，因爲游泳池，單線程的消息可能不按順序出現。如果你想訂購，你需要寫入一個（同步）隊列，並有一個專門的工作人員將數據（同步）從隊列中取出並寫入日誌文件。同樣，現有的日誌記錄框架將爲您解決這個問題。

來源

2012-07-28 15:23:44

不幸的是，現有的日誌框架由於許可，開源以及其他法律障礙而不存在問題。簡單的說，我需要提供一個線程安全的日誌記錄機制。保持文件鎖定沒問題...日誌通常不會被任何用戶讀取（除非我誤解了某些內容）。 – IAbstract 2012-07-28 17:09:13

感謝您的信息：我重新加入了一個排隊日誌「Action」的隊列，該隊列由一個Task對象監視。排隊和出隊在'lockQueue'對象上同步，因爲'隊列'沒有同步對象。 – IAbstract 2012-07-30 15:38:30

QueueUserWorkItem是否鎖定正確實現？

回答

相關問題