1. 程式人生 > >C# Invoke和BeginInvoke(1)

C# Invoke和BeginInvoke(1)

 近日,被Control的Invoke和BeginInvoke搞的頭大,就查了些相關的資料,整理如下。感謝這篇文章對我的理解Invoke和BeginInvoke的真正含義 。
(一)Control的Invoke和BeginInvoke
我們要基於以下認識:
(1)Control的Invoke和BeginInvoke與Delegate的Invoke和BeginInvoke是不同的。
(2)Control的Invoke和BeginInvoke的引數為delegate,委託的方法是在Control的執行緒上執行的,也就是我們平時所說的UI執行緒。

我們以程式碼(一)來看(Control的Invoke)
private delegate void InvokeDelegate();
private void InvokeMethod(){
   //C程式碼段
}
private void butInvoke_Click(object sender, EventArgs e) {
   //A程式碼段.......
   this.Invoke(new InvokeDelegate(InvokeMethod));
   //B程式碼段......
}


你覺得程式碼的執行順序是什麼呢?記好Control的Invoke和BeginInvoke都執行在主執行緒即UI執行緒上
A------>C---------------->B
解釋:(1)A在UI執行緒上執行完後,開始Invoke,Invoke是同步
(2)程式碼段B並不執行,而是立即在UI執行緒上執行InvokeMethod方法,即程式碼段C。
(3)InvokeMethod方法執行完後,程式碼段C才在UI執行緒上繼續執行。

看看程式碼(二),Control的BeginInvoke
private delegate void BeginInvokeDelegate();
private void BeginInvokeMethod(){
   //C程式碼段
}
private void butBeginInvoke_Click(object sender, EventArgs e) {
   //A程式碼段.......
   this.BeginInvoke(new BeginInvokeDelegate(BeginInvokeMethod));
   //B程式碼段......
}

你覺得程式碼的執行順序是什麼呢?記好Control的Invoke和BeginInvoke都執行在主執行緒即UI執行緒上
A----------->B--------------->C慎重,這個只做參考。。。。。,我也不肯定執行順序,如果有哪位達人知道的話請告知。
解釋::(1)A在UI執行緒上執行完後,開始BeginInvoke,BeginInvoke是非同步
(2)InvokeMethod方法,即程式碼段C不會執行,而是立即在UI執行緒上執行程式碼段B。
(3)程式碼段B執行完後(就是說butBeginInvoke_Click方法執行完後),InvokeMethod方法,即程式碼段C才在UI執行緒上繼續執行。

由此,我們知道:
Control的Invoke和BeginInvoke的委託方法是在主執行緒,即UI執行緒上執行的。也就是說如果你的委託方法用來取花費時間長的資料,然後更新介面什麼的,千萬別在UI執行緒上呼叫Control.Invoke和Control.BeginInvoke,因為這些是依然阻塞UI執行緒的,造成介面的假死。

那麼,這個非同步到底是什麼意思呢?

非同步是指相對於呼叫BeginInvoke的執行緒非同步,而不是相對於UI執行緒非同步,你在UI執行緒上呼叫BeginInvoke ,當然不行了。----摘自"Invoke和BeginInvoke的真正涵義"一文中的評論。
BeginInvoke的原理是將呼叫的方法Marshal成訊息,然後呼叫Win32 API中的RegisterWindowMessage()向UI視窗傳送訊息。----摘自"Invoke和BeginInvoke的真正涵義"一文中的評論。

(二)我們用Thread來呼叫BeginInvoke和Invoke
      我們開一個執行緒,讓執行緒執行一些耗費時間的操作,然後再用Control.Invoke和Control.BeginInvoke回到使用者UI執行緒,執行介面更新。

程式碼(三)  Thread呼叫Control的Invoke
private Thread invokeThread;
private delegate void invokeDelegate();
private void StartMethod(){
   //C程式碼段......
   Control.Invoke(new invokeDelegate(invokeMethod));
  //D程式碼段......
}
private void invokeMethod(){
  //E程式碼段
}
private void butInvoke_Click(object sender, EventArgs e) {
   //A程式碼段.......
   invokeThread = new Thread(new ThreadStart(StartMethod));
   invokeThread.Start();
   //B程式碼段......
}

你覺得程式碼的執行順序是什麼呢?記好Control的Invoke和BeginInvoke都執行在主執行緒即UI執行緒上
A------>(Start一開始B和StartMethod的C就同時執行)---->(C執行完了,不管B有沒有執行完,invokeThread把訊息封送(invoke)給UI執行緒,然後自己等待)---->UI執行緒處理完butInvoke_Click訊息後,處理invokeThread封送過來的訊息,執行invokeMethod方法,即程式碼段E,處理往後UI執行緒切換到invokeThread執行緒。
這個Control.Invoke是相對於invokeThread執行緒同步的,阻止了其執行。

解釋:
1。UI執行A
2。UI開執行緒InvokeThread,B和C同時執行,B執行線上程UI上,C執行線上程invokeThread上。
3。invokeThread封送訊息給UI,然後自己等待,UI處理完訊息後,處理invokeThread封送的訊息,即程式碼段E
4。UI執行完E後,轉到執行緒invokeThread上,invokeThread執行緒執行程式碼段D

程式碼(四)  Thread呼叫Control的BeginInvoke
private Thread beginInvokeThread;
private delegate void beginInvokeDelegate();
private void StartMethod(){
   //C程式碼段......
   Control.BeginInvoke(new beginInvokeDelegate(beginInvokeMethod));
  //D程式碼段......
}
private void beginInvokeMethod(){
  //E程式碼段
}
private void butBeginInvoke_Click(object sender, EventArgs e) {
   //A程式碼段.......
   beginInvokeThread = new Thread(new ThreadStart(StartMethod));
   beginInvokeThread .Start();
   //B程式碼段......
}

你覺得程式碼的執行順序是什麼呢?記好Control的Invoke和BeginInvoke都執行在主執行緒即UI執行緒上
A在UI執行緒上執行----->beginInvokeThread執行緒開始執行,UI繼續執行程式碼段B,併發地invokeThread執行程式碼段C-------------->不管UI有沒有執行完程式碼段B,這時beginInvokeThread執行緒把訊息封送給UI,單自己並不等待,繼續向下執行-------->UI處理完butBeginInvoke_Click訊息後,處理beginInvokeThread執行緒封送過來的訊息。


解釋:
1。UI執行A
2。UI開執行緒beginInvokeThread,B和C同時執行,B執行線上程UI上,C執行線上程beginInvokeThread上。
3。beginInvokeThread封送訊息給UI,然後自己繼續執行程式碼D,UI處理完訊息後,處理invokeThread封送的訊息,即程式碼段E
有點疑問:如果UI先執行完畢,是不是有可能過了段時間beginInvokeThread才把訊息封送給UI,然後UI才繼續執行封送的訊息E。如圖淺綠的部分。


Control的BeginInvoke是相對於呼叫它的執行緒,即beginInvokeThread相對是非同步的。
因此,我們可以想到。如果要非同步取耗費長時間的資料,比如從資料庫中讀大量資料,我們應該這麼做。

(1)如果你想阻止呼叫執行緒,那麼呼叫程式碼(三),程式碼段D刪掉,C改為耗費長時間的操作,因為這個操作是在另外一個執行緒中做的。程式碼段E改為更新介面的方法。
(2)如果你不想阻止呼叫執行緒,那麼呼叫程式碼(四),程式碼段D刪掉,C改為耗費長時間的操作,因為這個操作是在另外一個執行緒中做的。程式碼段E改為更新介面的方法。


相關知識:1。Invoke 和 BeginInvoke 的真正涵義

一、為什麼Control類提供了Invoke和BeginInvoke機制?

關於這個問題的最主要的原因已經是dotnet程式設計師眾所周知的,我在此費點筆墨再次記錄到自己的日誌,以便日後提醒一下自己。

1、windows程式訊息機制

Windows GUI程式是基於訊息機制的,有個主執行緒維護著一個訊息泵。這個訊息泵讓windows程式生生不息。

                                                  Windows GUI程式的訊息迴圈

 

 

Windows程式有個訊息佇列,窗體上的所有訊息是這個佇列裡面訊息的最主要來源。這裡的while迴圈使用了GetMessage()這個方法,這是個阻塞方法,也就是佇列為空時方法就會被阻塞,從而這個while迴圈停止運動,這避免了一個程式把cpu無緣無故地耗盡,讓其它程式難以得到響應。當然在某些需要cpu最大限度運動的程式裡面就可以使用另外的方法,例如某些3d遊戲或者及時戰略遊戲中,一般會使用PeekMessage()這個方法,它不會被windows阻塞,從而保證整個遊戲的流暢和比較高的幀速。

這個主執行緒維護著整個窗體以及上面的子控制元件。當它得到一個訊息,就會呼叫DispatchMessage方法派遣訊息,這會引起對窗體上的視窗過程的呼叫。視窗過程裡面當然是程式設計師提供的窗體資料更新程式碼和其它程式碼。

2、dotnet裡面的訊息迴圈

public static void Main(string[] args)

{

   Form f = new Form();

   Application.Run(f);

}

Dotnet窗體程式封裝了上述的while迴圈,這個迴圈就是通過Application.Run方法啟動的。

3、執行緒外操作GUI控制元件的問題

如果從另外一個執行緒操作windows窗體上的控制元件,就會和主執行緒產生競爭,造成不可預料的結果,甚至死鎖。因此windows GUI程式設計有一個規則,就是隻能通過建立控制元件的執行緒來操作控制元件的資料,否則就可能產生不可預料的結果。

因此,dotnet裡面,為了方便地解決這些問題,Control類實現了ISynchronizeInvoke介面,提供了Invoke和BeginInvoke方法來提供讓其它執行緒更新GUI介面控制元件的機制。

public interface ISynchronizeInvoke

{

        [HostProtection(SecurityAction.LinkDemand, Synchronization=true, ExternalThreading=true)]

        IAsyncResult BeginInvoke(Delegate method, object[] args);

        object EndInvoke(IAsyncResult result);

        object Invoke(Delegate method, object[] args);

        bool InvokeRequired { get; }

}

}

如果從執行緒外操作windows窗體控制元件,那麼就需要使用Invoke或者BeginInvoke方法,通過一個委託把呼叫封送到控制元件所屬的執行緒上執行。

二、訊息機制---執行緒間和程序間通訊機制

1、window訊息傳送

Windows訊息機制是windows平臺上的執行緒或者程序間通訊機制之一。Windows訊息值其實就是定義的一個數據結構,最重要的是訊息的型別,它就是一個整數;然後就是訊息的引數。訊息的引數可以表示很多東西。

Windows提供了一些api用來向一個執行緒的訊息佇列傳送訊息。因此,一個執行緒可以向另一個執行緒的訊息佇列傳送訊息從而告訴對方做什麼,這樣就完成了執行緒間的通訊。有些api傳送訊息需要一個視窗控制代碼,這種函式可以把訊息傳送到指定視窗的主執行緒訊息佇列;而有些則可以直接通過執行緒控制代碼,把訊息傳送到該執行緒訊息佇列中。

                                                   

 

用訊息機制通訊

 

SendMessage是windows api,用來把一個訊息傳送到一個視窗的訊息佇列。這個方法是個阻塞方法,也就是作業系統會確保訊息的確傳送到目的訊息佇列,並且該訊息被處理完畢以後,該函式才返回。返回之前,呼叫者將會被暫時阻塞。

PostMessage也是一個用來發送訊息到視窗訊息佇列的api函式,但這個方法是非阻塞的。也就是它會馬上返回,而不管訊息是否真的傳送到目的地,也就是呼叫者不會被阻塞。

2、Invoke and BeginInvoke

 

 

                                                        Invoke or BeginInvoke

 

Invoke或者BeginInvoke方法都需要一個委託物件作為引數。委託類似於回撥函式的地址,因此呼叫者通過這兩個方法就可以把需要呼叫的函式地址封送給介面執行緒。這些方法裡面如果包含了更改控制元件狀態的程式碼,那麼由於最終執行這個方法的是介面執行緒,從而避免了競爭條件,避免了不可預料的問題。如果其它執行緒直接操作介面執行緒所屬的控制元件,那麼將會產生競爭條件,造成不可預料的結果。

使用Invoke完成一個委託方法的封送,就類似於使用SendMessage方法來給介面執行緒傳送訊息,是一個同步方法。也就是說在Invoke封送的方法被執行完畢前,Invoke方法不會返回,從而呼叫者執行緒將被阻塞。

使用BeginInvoke方法封送一個委託方法,類似於使用PostMessage進行通訊,這是一個非同步方法。也就是該方法封送完畢後馬上返回,不會等待委託方法的執行結束,呼叫者執行緒將不會被阻塞。但是呼叫者也可以使用EndInvoke方法或者其它類似WaitHandle機制等待非同步操作的完成。

但是在內部實現上,Invoke和BeginInvoke都是用了PostMessage方法,從而避免了SendMessage帶來的問題。而Invoke方法的同步阻塞是靠WaitHandle機制來完成的。

3、使用場合問題

如果你的後臺執行緒在更新一個UI控制元件的狀態後不需要等待,而是要繼續往下處理,那麼你就應該使用BeginInvoke來進行非同步處理。

如果你的後臺執行緒需要操作UI控制元件,並且需要等到該操作執行完畢才能繼續執行,那麼你就應該使用Invoke。否則,在後臺執行緒和主截面執行緒共享某些狀態資料的情況下,如果不同步呼叫,而是各自繼續執行的話,可能會造成執行序列上的問題,雖然不發生死鎖,但是會出現不可預料的顯示結果或者資料處理錯誤。

可以看到ISynchronizeInvoke有一個屬性,InvokeRequired。這個屬性就是用來在程式設計的時候確定,一個物件訪問UI控制元件的時候是否需要使用Invoke或者BeginInvoke來進行封送。如果不需要那麼就可以直接更新。在呼叫者物件和UI物件同屬一個執行緒的時候這個屬性返回false。在後面的程式碼分析中我們可以看到,Control類對這一屬性的實現就是在判斷呼叫者和控制元件是否屬於同一個執行緒的。

三、Delegate.BeginInvoke

通過一個委託來進行同步方法的非同步呼叫,也是.net提供的非同步呼叫機制之一。但是Delegate.BeginInvoke方法是從ThreadPool取出一個執行緒來執行這個方法,以獲得非同步執行效果的。也就是說,如果採用這種方式提交多個非同步委託,那麼這些呼叫的順序無法得到保證。而且由於是使用執行緒池裡面的執行緒來完成任務,使用頻繁,會對系統的效能造成影響。

Delegate.BeginInvoke也是講一個委託方法封送到其它執行緒,從而通過非同步機制執行一個方法。呼叫者執行緒則可以在完成封送以後去繼續它的工作。但是這個方法封送到的最終執行執行緒是執行庫從ThreadPool裡面選取的一個執行緒。

這裡需要糾正一個誤區,那就是Control類上的非同步呼叫BeginInvoke並沒有開闢新的執行緒完成委託任務,而是讓介面控制元件的所屬執行緒完成委託任務的。看來非同步操作就是開闢新執行緒的說法不一定準確。

 

終於看到了,這是在判斷windows窗體執行緒和當前的呼叫者執行緒是否是同一個,如果是同一個就沒有必要封送了,直接訪問這個GUI控制元件吧。否則,就不要那麼直接表白了,就需要Invoke或者BeginInvoke做媒了。

 

五、C#多執行緒 Invoke方法的使用 

在多執行緒程式設計中,我們經常要在工作執行緒中去更新介面顯示,而在多執行緒中直接呼叫介面控制元件的方法是錯誤的做法,Invoke 和 BeginInvoke 就是為了解決這個問題而出現的,使你在多執行緒中安全的更新介面顯示。

正確的做法是將工作執行緒中涉及更新介面的程式碼封裝為一個方法,通過 Invoke 或者 BeginInvoke 去呼叫,兩者的區別就是一個導致工作執行緒等待,而另外一個則不會。

而所謂的“一面響應操作,一面新增節點”永遠只能是相對的,使 UI 執行緒的負擔不至於太大而已,因為介面的正確更新始終要通過 UI 執行緒去做,我們要做的事情是在工作執行緒中包攬大部分的運算,而將對純粹的介面更新放到 UI 執行緒中去做,這樣也就達到了減輕 UI 執行緒負擔的目的了。

再舉個簡單例子說明下使用方法,比如你在啟動一個執行緒,線上程的方法中想更新窗體中的一個TextBox..

using System.Threading;

         public delegate void MyInvoke(string str);

         private void btnStartThread_Click(object sender, EventArgs e)         {            
            Thread thread = new Thread(new ThreadStart(DoWord));
            thread.Start();        
                             }

     public void DoWord()  { 

           MyInvoke mi = new MyInvoke(SetTxt);

            BeginInvoke(mi,new object[]{"abc"}); 
                       }

        public void SetTxt(string str)
        {
            txtReceive.Text += str + System.Environment.NewLine;
        } 

////////////////////////

 

Version:1.0 StartHTML:000000229 EndHTML:000056226 StartFragment:000001686 EndFragment:000056170 StartSelection:000002095 EndSelection:000056166 SourceURL:http://www.cnblogs.com/worldreason/archive/2008/06/09/1216127.htmlInvoke and BeginInvoke - 資訊加油站義工 - 部落格園


在Invoke或者BeginInvoke的使用中無一例外地使用了委託Delegate,至於委託的本質請參考我的另一隨筆:對.net事件的看法

一、為什麼Control類提供了Invoke和BeginInvoke機制?

關於這個問題的最主要的原因已經是dotnet程式設計師眾所周知的,我在此費點筆墨再次記錄到自己的日誌,以便日後提醒一下自己。

1、windows程式訊息機制

Windows GUI程式是基於訊息機制的,有個主執行緒維護著一個訊息泵。這個訊息泵讓windows程式生生不息。

                                                  Windows GUI程式的訊息迴圈
 

 

Windows程式有個訊息佇列,窗體上的所有訊息是這個佇列裡面訊息的最主要來源。這裡的while迴圈使用了GetMessage()這個方法,這是個阻塞方法,也就是佇列為空時方法就會被阻塞,從而這個while迴圈停止運動,這避免了一個程式把cpu無緣無故地耗盡,讓其它程式難以得到響應。當然在某些需要cpu最大限度運動的程式裡面就可以使用另外的方法,例如某些3d遊戲或者及時戰略遊戲中,一般會使用PeekMessage()這個方法,它不會被windows阻塞,從而保證整個遊戲的流暢和比較高的幀速。

這個主執行緒維護著整個窗體以及上面的子控制元件。當它得到一個訊息,就會呼叫DispatchMessage方法派遣訊息,這會引起對窗體上的視窗過程的呼叫。視窗過程裡面當然是程式設計師提供的窗體資料更新程式碼和其它程式碼。

2、dotnet裡面的訊息迴圈

public static void Main(string[] args)

{

   Form f = new Form();

   Application.Run(f);

}

Dotnet窗體程式封裝了上述的while迴圈,這個迴圈就是通過Application.Run方法啟動的。

3、執行緒外操作GUI控制元件的問題

如果從另外一個執行緒操作windows窗體上的控制元件,就會和主執行緒產生競爭,造成不可預料的結果,甚至死鎖。因此windows GUI程式設計有一個規則,就是隻能通過建立控制元件的執行緒來操作控制元件的資料,否則就可能產生不可預料的結果。

因此,dotnet裡面,為了方便地解決這些問題,Control類實現了ISynchronizeInvoke介面,提供了InvokeBeginInvoke方法來提供讓其它執行緒更新GUI介面控制元件的機制。

public interface ISynchronizeInvoke

{

        [HostProtection(SecurityAction.LinkDemand, Synchronization=true, ExternalThreading=true)]

        IAsyncResult BeginInvoke(Delegate method, object[] args);

        object EndInvoke(IAsyncResult result);

        object Invoke(Delegate method, object[] args);

        bool InvokeRequired { get; }

}

}

如果從執行緒外操作windows窗體控制元件,那麼就需要使用Invoke或者BeginInvoke方法,通過一個委託把呼叫封送到控制元件所屬的執行緒上執行。

二、訊息機制---執行緒間和程序間通訊機制

1、window訊息傳送

Windows訊息機制是windows平臺上的執行緒或者程序間通訊機制之一。Windows訊息值其實就是定義的一個數據結構,最重要的是訊息的型別,它就是一個整數;然後就是訊息的引數。訊息的引數可以表示很多東西。

Windows提供了一些api用來向一個執行緒的訊息佇列傳送訊息。因此,一個執行緒可以向另一個執行緒的訊息佇列傳送訊息從而告訴對方做什麼,這樣就完成了執行緒間的通訊。有些api傳送訊息需要一個視窗控制代碼,這種函式可以把訊息傳送到指定視窗的主執行緒訊息佇列;而有些則可以直接通過執行緒控制代碼,把訊息傳送到該執行緒訊息佇列中。

                                                   

 

用訊息機制通訊

 

SendMessage是windows api,用來把一個訊息傳送到一個視窗的訊息佇列。這個方法是個阻塞方法,也就是作業系統會確保訊息的確傳送到目的訊息佇列,並且該訊息被處理完畢以後,該函式才返回。返回之前,呼叫者將會被暫時阻塞。

PostMessage也是一個用來發送訊息到視窗訊息佇列的api函式,但這個方法是非阻塞的。也就是它會馬上返回,而不管訊息是否真的傳送到目的地,也就是呼叫者不會被阻塞。

2、Invoke and BeginInvoke

 

 

                                                        Invoke or BeginInvoke

 

Invoke或者BeginInvoke方法都需要一個委託物件作為引數。委託類似於回撥函式的地址,因此呼叫者通過這兩個方法就可以把需要呼叫的函式地址封送給介面執行緒。這些方法裡面如果包含了更改控制元件狀態的程式碼,那麼由於最終執行這個方法的是介面執行緒,從而避免了競爭條件,避免了不可預料的問題。如果其它執行緒直接操作介面執行緒所屬的控制元件,那麼將會產生競爭條件,造成不可預料的結果。

使用Invoke完成一個委託方法的封送,就類似於使用SendMessage方法來給介面執行緒傳送訊息,是一個同步方法。也就是說在Invoke封送的方法被執行完畢前,Invoke方法不會返回,從而呼叫者執行緒將被阻塞。

使用BeginInvoke方法封送一個委託方法,類似於使用PostMessage進行通訊,這是一個非同步方法。也就是該方法封送完畢後馬上返回,不會等待委託方法的執行結束,呼叫者執行緒將不會被阻塞。但是呼叫者也可以使用EndInvoke方法或者其它類似WaitHandle機制等待非同步操作的完成。

但是在內部實現上,Invoke和BeginInvoke都是用了PostMessage方法,從而避免了SendMessage帶來的問題。而Invoke方法的同步阻塞是靠WaitHandle機制來完成的。

3、使用場合問題

如果你的後臺執行緒在更新一個UI控制元件的狀態後不需要等待,而是要繼續往下處理,那麼你就應該使用BeginInvoke來進行非同步處理。

如果你的後臺執行緒需要操作UI控制元件,並且需要等到該操作執行完畢才能繼續執行,那麼你就應該使用Invoke。否則,在後臺執行緒和主截面執行緒共享某些狀態資料的情況下,如果不同步呼叫,而是各自繼續執行的話,可能會造成執行序列上的問題,雖然不發生死鎖,但是會出現不可預料的顯示結果或者資料處理錯誤。

可以看到ISynchronizeInvoke有一個屬性,InvokeRequired。這個屬性就是用來在程式設計的時候確定,一個物件訪問UI控制元件的時候是否需要使用Invoke或者BeginInvoke來進行封送。如果不需要那麼就可以直接更新。在呼叫者物件和UI物件同屬一個執行緒的時候這個屬性返回false。在後面的程式碼分析中我們可以看到,Control類對這一屬性的實現就是在判斷呼叫者和控制元件是否屬於同一個執行緒的。

三、Delegate.BeginInvoke

通過一個委託來進行同步方法的非同步呼叫,也是.net提供的非同步呼叫機制之一。但是Delegate.BeginInvoke方法是從ThreadPool取出一個執行緒來執行這個方法,以獲得非同步執行效果的。也就是說,如果採用這種方式提交多個非同步委託,那麼這些呼叫的順序無法得到保證。而且由於是使用執行緒池裡面的執行緒來完成任務,使用頻繁,會對系統的效能造成影響。

Delegate.BeginInvoke也是講一個委託方法封送到其它執行緒,從而通過非同步機制執行一個方法。呼叫者執行緒則可以在完成封送以後去繼續它的工作。但是這個方法封送到的最終執行執行緒是執行庫從ThreadPool裡面選取的一個執行緒。

這裡需要糾正一個誤區,那就是Control類上的非同步呼叫BeginInvoke並沒有開闢新的執行緒完成委託任務,而是讓介面控制元件的所屬執行緒完成委託任務的。看來非同步操作就是開闢新執行緒的說法不一定準確。 

四、用Reflector察看一些相關程式碼

1、Control.BeginInvoke and Control.Invoke

public IAsyncResult BeginInvoke(Delegate method, params object[] args)
{
    using (new MultithreadSafeCallScope())
    {
        return (IAsyncResult) this.FindMarshalingControl().MarshaledInvoke(this, method, args, false);
    }
}
public object Invoke(Delegate method, params object[] args)
{
    using (new MultithreadSafeCallScope())
    {
        return this.FindMarshalingControl().MarshaledInvoke(this, method, args, true);
    }
}

這裡的FindMarshalingControl方法通過一個迴圈向上回溯,從當前控制元件開始回溯父控制元件,直到找到最頂級的父控制元件,用它作為封送物件。例如,我們呼叫窗體上一個進度條的Invoke方法封送委託,但是實際上會回溯到主窗體,通過這個控制元件物件來封送委託。因為主窗體是主執行緒訊息佇列相關的,傳送給主窗體的訊息才能傳送到介面主執行緒訊息佇列。

我們可以看到Invoke和BeginInvoke方法使用了同樣的實現,只是MarshaledInvoke方法的最後一個引數值不一樣。

2、MarshaledInvoke

private object MarshaledInvoke(Control caller, Delegate method, object[] args, bool synchronous)
{
    int num;
    if (!this.IsHandleCreated)
    {
        throw new InvalidOperationException(SR.GetString("ErrorNoMarshalingThread"));
    }
    if (((ActiveXImpl) this.Properties.GetObject(PropActiveXImpl)) != null)
    {
        IntSecurity.UnmanagedCode.Demand();
    }
    bool flag = false;
    if ((SafeNativeMethods.GetWindowThreadProcessId(new HandleRef(this, this.Handle), out num) == SafeNativeMethods.GetCurrentThreadId()) && synchronous)
    {
        flag = true;
    }
    ExecutionContext executionContext = null;
    if (!flag)
    {
        executionContext = ExecutionContext.Capture();
    }
    ThreadMethodEntry entry = new ThreadMethodEntry(caller, method, args, synchronous, executionContext);
    lock (this)
    {
        if (this.threadCallbackList == null)
        {
            this.threadCallbackList = new Queue();
        }
    }
    lock (this.threadCallbackList)
    {
        if (threadCallbackMessage == 0)
        {
            threadCallbackMessage = SafeNativeMethods.RegisterWindowMessage(Application.WindowMessagesVersion + "_ThreadCallbackMessage");
        }
        this.threadCallbackList.Enqueue(entry);
    }
    if (flag)
    {
        this.InvokeMarshaledCallbacks();
    }
    else
    {            //終於找到你了,PostMessage
        UnsafeNativeMethods.PostMessage(new HandleRef(this, this.Handle), threadCallbackMessage, IntPtr.Zero, IntPtr.Zero);
    }
    if (!synchronous) //如果是非同步,那麼馬上返回吧
    {
        return entry;
    }
    if (!entry.IsCompleted) //同步呼叫沒結束,阻塞起來等待吧
    {
        this.WaitForWaitHandle(entry.AsyncWaitHandle);
    }
    if (entry.exception != null)
    {
        throw entry.exception;
    }
    return entry.retVal;
}

怎麼樣,我們終於看到PostMessage了吧?通過windows訊息機制實現了封送。而需要封送的委託方法作為訊息的引數進行了傳遞。關於其它的程式碼這裡不作進一步解釋。

3、InvokeRequired

public bool InvokeRequired
{
    get
    {
        using (new MultithreadSafeCallScope())
        {
            HandleRef ref2;
            int num;
            if (this.IsHandleCreated)
            {
                ref2 = new HandleRef(this, this.Handle);
            }
            else
            {
                Control wrapper = this.FindMarshalingControl();
                if (!wrapper.IsHandleCreated)
                {
                    return false;
                }
                ref2 = new HandleRef(wrapper, wrapper.Handle);
            }
            int windowThreadProcessId = SafeNativeMethods.GetWindowThreadProcessId(ref2, out num);
            int currentThreadId = SafeNativeMethods.GetCurrentThreadId();
            return (windowThreadProcessId != currentThreadId);
        }
    }

}

終於看到了,這是在判斷windows窗體執行緒和當前的呼叫者執行緒是否是同一個,如果是同一個就沒有必要封送了,直接訪問這個GUI控制元件吧。否則,就不要那麼直接表白了,就需要Invoke或者BeginInvoke做媒了。