WCF筆記–併發管理

 剛剛吃完飯,,很飽很飽..感謝兄弟夥了..我都記在心裡



 傳入客戶端呼叫都會被分發到windows執行緒池做統一處理,在使用時我們還必要要提供執行緒安全訪問等過程..

 這就可能要設計到執行緒同步的問題了,WCF提供了兩種關於執行緒同步的方案 1.自動同步 2.手動同步(可能需要大家付出更多的程式碼來維護服務的狀態了)  

 1.自動同步

 這種方式比較簡單,是在我們的服務行為(ServiceBehavior)中進行管理 [ConcurrencyMode]

 這個宣告式標籤有三個屬性值,其分別是 Single(單例),Reentrant(單例),Multiple(併發)

 Single沒什麼還說的,重點看一下Reentrant的服務重入與Multiple的併發鎖定


 服務在配置成Reentrant模式時,最好是使用回撥契約無返回值的情況,我們知道單例模式的操作,當服務被呼叫時WCF會鎖定上下文資源物件

 這樣的話我們再去使用回撥函式,當回撥函式返回後,就可能會造成服務死鎖的狀況…這也是使用Reentrant模式的意義所在,這種定義可以在服務重入的時候重新加鎖鎖定資源…


 服務在配置成Multiple模式時,其實使用Monitor鎖定(lock)區域性物件還是會發生死鎖問題,試想如果鎖定整個方法主體呢?個人認為這樣的鎖定不靈活,顆粒度也過於粗,沒有意義了…ms也想到了此問題,最佳的解決方案就是直接引入編譯器!,

利用編譯器將我們的呼叫物件自動對例項加鎖
 [MethodImpl(MethodImplOptions.Synchronized)],不過問題還沒有結束,,如果我的部分方法不需要同步訪問呢?當然我們還可以
 [ReleaseServiceInstanceOnTransactionComple=false],這樣就可以完美的解決在併發中的同步問題了
 注: 當然使用服務型別共享鎖也是可以解決死鎖問題的.


 2.手動同步
 在手動同步中,我們可能更多的要和同步上下文打交道了SynchronizationContext , 注:同步上下文使用沒有確定的object物件,不是型別安全的物件,使用時需要注意.
 封裝同步上下文示意


 class MyResource
 {
       SynchronizationContext MySynchronizationContext;

       public int DoWork()

       {
           int result = 0;

           SendOrPostCallBack doWork = delegate { result = DoWorkInternal(); }
           MySynchronizationContext.Send(doWork,null);
           return result;
       }


       int DoWorkInternal()
       {
           return 2;
       }
 }

 class MyService : IMyContract
 {
       MyResource GetResource()
       {
           return new MyResource();

       }


       public void MyMethod()
       {
           MyResource resource = GetResource();
           int result = resource.DoWork();

       }
 } 


  非同步呼叫需要使用IAsycnResult介面,注意的是實現此介面呼叫服務的話,需要傳入ref標識同步值,InterLocker呼叫去處理標識同步值
  輪詢或等待完成,需要使用到非同步物件的AsyncWaitHandle的WaitOne與WaitAll方法,






     本文轉自My_King1 51CTO部落格，原文連結：http://blog.51cto.com/apprentice/1360555，如需轉載請自行聯絡原作者