WCF回調，代理和線程安全

Question

給出一個WCF雙工服務（NetTcpBinding的），用於創建爲每個新客戶新的服務實例（見pattern publish-subscribe），就可以得到回調的一個具體實例爲每個服務實例。由於創建了不同的實例，因此可以同時從不同的線程調用屬於不同回調的方法。

• 如果多個線程試圖在同一個回調中調用相同的方法會發生什麼？
• 如果他們試圖調用不同的方法，但對於相同的回調會發生什麼？
• 我們應該從多個線程管理這些方法的併發訪問嗎？在這兩種情況下？

現在考慮與服務通信的客戶端：爲了確保客戶端可以使用該服務，必須實例化一個新代理，並且爲了調用服務中定義的方法，必須調用代理的相應方法。

• 如果多個線程嘗試在相同的代理實例上調用相同的方法會發生什麼？
• 如果他們試圖調用不同的方法，但對於同一代理實例會發生什麼？
• 我們應該從多個線程管理這些方法的併發訪問嗎？在這兩種情況下？

Answer 1

大多數的這些問題的答案取決於你如何管理你的服務的併發。沒有明確的答案，因爲它取決於您爲ConcurrencyMode和InstanceContextMode設置的內容。 WCF的併發管理將使您能夠微調服務的線程行爲和性能。在concurrency management is available on MSDN上閱讀了一段漫長而艱辛（但非常詳細）的文章。

的InstanceContextMode允許您定義您的服務應如何被實例化。對於執行大量繁重工作並處理大量呼叫的服務，總體思路是使用PerCall實例化，因爲此設置傳入的客戶端請求將每次在服務的單獨實例上處理。

ConcurrencyMode，主播放器，將alow您可以定義多個線程如何在給定的時間內訪問服務實例。在ConcurrencyMode=Single中，一次只有一個線程可以訪問服務實例。這還取決於您是否啓用了SynchronizationConext，如果SynchronizationConext=true那麼客戶端呼叫將排隊，如果您的服務正在應答另一個請求的過程中。所以傳入的服務呼叫將排隊，直到先前的呼叫被處理。使用ConcurrencyMode=Multiple設置，允許任意數量的線程訪問服務實例，這意味着您的服務可以儘可能多地應答呼叫，因爲線程池中有多少線程（與CPU能力直接相關）可用。具有多種併發模式的捕獲方式是，您的服務在接收和響應調用時的順序並不如此可靠，因爲狀態將不會被管理，因爲SynchronizationContext默認設置爲false。關於​​的簡短摘要。結合InstanceContext模式下使用時

這些設置會影響您的服務表現，看看this pretty nice article which explores various concurrency modes and instance context settings and their effects on performance（雖然似乎結果是隻有在自託管環境中，可能並不能代表時序太託管的時候，你會得到IIS）。

您管理服務的併發性的方式將極大地影響其性能。理想情況下，您希望儘可能多地使用線程（嘗試增加ThreadPool的最小線程）到服務中，並且只要服務具有可供處理的計算資源，就可以避免傳入的服務調用排隊等候。但是，過度使用多線程會犧牲狀態管理和響應客戶端請求的順序。