我可能會繼承一套較爲複雜的多線程應用程序，它目前擁有2 + K LOC幾個文件，很多來自世界各地的訪問全局變量和其他做法的，我會考慮的很臭。策略多線程應用程序
在我開始增加與當前模式的新功能，我想試試，看看我可以讓應用程序的基本架構更好。這裏有一個簡短的說明：
我有點對我應該看看，以有知識，使這個最好的決定有什麼不同的模式，戰略，規劃實踐等麻煩。
這裏的一些目標，我已經發明瞭自己：
感謝您的任何關鍵字或其他的技巧，這可以幫助我在這個項目上。
我建議另一個目標是刪除/減少全局狀態，並保持在堆棧上的信息儘可能多地減少競爭條件和怪異的線程問題的可能性。
也許它可能是值得看的，如果你可以將TA2，點tB2，Ta3與TB3到同一個線程殺幾個。如果這是不可能的，可以考慮將它們放在一個Facade（一個線程，該線程涉及在UI和與服務器交談的服務之間移動數據請求）。這是「面向用戶」的代碼只需要處理一個客戶而不是兩個客戶。 （我不把備份當作客戶端，因爲這聽起來像是單向過程）。
如果線程（UI和立面）彼此等待完成他們的請求，那麼這應該防止出現「拉更新」在同一時間發生的事情爲「推進更新」。
「可以通過刪除/減少全局狀態並儘可能多地保存堆棧上的信息」您能澄清一下嗎，我不確定您的堆棧是什麼意思？ – Morri 2009-12-01 16:27:44
堆棧我的意思是傳入當前方法的參數。這是堆棧頂部的內容。如果您刪除全局狀態，而是想方設法將相關信息作爲參數傳遞（甚至可能使用深複製來避免對線程A上的引用進行操作以更改線程B正在處理的數據），您將極大地降低線程問題。請閱讀「純度」的概念，特別是關於原始概念的功能性編程。 – Quibblesome 2009-12-01 16:33:46
http://en.wikipedia.org/wiki/Pure_function是純度的前提。關於「純」代碼的最好的事情是沒有競爭條件。關於「純」代碼最糟糕的是技術上它不能做任何有用的事情（技術上Console.WriteLine是不純的）。但是這個概念值得讚賞，特別是在處理線程時。 – Quibblesome 2009-12-01 16:39:09
爲了做出這樣的變化，一般你會想看看Martin Fowler的Refactoring: Improving the Design of Existing Code（其中大部分是在the refactoring website）以及Refactoring to Patterns。您也可能會發現Working Effectively with Legacy Code對支持安全更改很有用。這些都不是專門用於多線程的幫助，除了簡單的代碼在多線程環境中更容易處理。
對於Quibblesome的優秀建議，我可能還補充說使用immutable objects通常是降低線程問題風險的有效方法。 （像.NET和Java中的字符串一樣，不可變對象在創建後無法修改。）
感謝您的評論。我會檢查那些，但是現在我陷入了2.0的世界，所以在vs2010和4.0中可能的解決方案几乎不在我的範圍之內。 – Morri 2009-12-01 15:46:51