我正在處理我的第一個涉及一些基本線程/並行性的Windows服務項目。到目前爲止它一直非常強烈,但我慢慢開始理解線程(我想我們會看到這個...)。等待線程在Windows服務中停止
我有一個Windows服務將包含2鬆散耦合的工作線程。線程A將從FTP服務器上下載文件,解壓/準備它們並保存到另一個目錄,其中線程B將有一個FileSystemWatcher監視。線程B將解析這些文件,對這些數據做許多事情,進行一些http調用,最後歸檔並從工作目錄中刪除這些文件。
我剛開始工作,現在我面臨的問題是如何等待線程A和線程B返回。我看着這個問題:Thread.Join on multiple threads with timeout並有一個想法。
問題是,如果我們等待x線程返回ax每秒的第二個超時,並且有足夠的線程,即使在正常操作下服務也可能顯示爲不響應(我在SCM抱怨之前讀取超時爲30秒,對?)。另外,如果我們通過跟蹤剩餘時間來解決這個問題,就像我們在線程上循環一樣,我們在工作集合開始處等待線程的時間越長,剩餘線程返回的時間就越短 - 最終如果線程足夠多,即使所有線程都在預期的時間內返回,服務仍將顯示爲無響應。
在這種情況下,我可能只是在14秒的時間內在A和B上加入thread.join,因爲我只有兩個工人,14秒似乎有足夠的時間返回兩個工人。
如果我有可變數量的工作線程(假設大於8)是否值得做這樣的事情?這會工作可靠嗎?
注意:不要使用以下內容 - 這是多層次上的一個壞主意。見答案
protected override void OnStop()
{
// the service is stopping - set the event
Worker.ThreadStopEvent.Set();
// stop the threads
Parallel.ForEach(_workerThreads, t =>
{
t.Join(new TimeSpan(0, 0, 28));
});
}
+1你的答案是最多方面的,並且是首先提到CountdownEvent,這似乎是要走的路。 – HAL9000 2011-04-05 22:34:31