For synchronization programmers often use a Form object that contains controls requiring content update. They probably do it because it’s so easy to implement. It’s so easy to call the following code:

myForm.BeginInvoke(new MethodInvoker(()=>
{
    //a code to be executed in the GUI thread
}), null);

However, simple doesn’t mean correct! GUI thread is not a separate control property but something that is used by all controls. GUI thread lifetime exceeds lifetime of an individual control. Controls and forms can be created or deleted, and all these operations are done via message loop common for all controls and forms. Now let’s say that we started synchronization via myForm.BeginInvoke() upon notification from non-GUI thread. This call adds a window message to message loop. When this message is processed, window handle associated with it is dispatched to specified control or form, and after that a delegate is called. So, what if the form has been closed before that? An exception will be thrown during dispatching. Don’t think that this situation is unusual. When application terminates, it closes windows and performs various actions with end devices, IP stack, etc. These devices in turn may notify GUI of their termination followed by synchronization. This may cause frequent exceptions that are hard to understand and even harder to fix.

We are absolutely convinced that there is only one way out – to create a global dispatcher that is initialized when application starts and is closed when it stops. Dispatcher may be based on the main form launched in Application.Run(). All multi-threaded synchronization should be performed only via this dispatcher. Besides, this approach enables use of other dispatcher for unit tests. As an example we will demonstrate this idea with a code:

//Dispatcher class
static class Dispatcher
{
    private static ISynchronizeInvoke _invoker;

    internal static void Init(ISynchronizeInvoke invoker) {_invoker = invoker;}

    public static ISynchronizeInvoke GuiDispatcher { get { return _invoker; }}
}

//How to initialize
using (Form mainForm = new Form())
{
    Dispatcher.Init(mainForm);

    //other initialization code...

    //Start the main loop as usual
    Application.Run(mainForm);
}

//How to use:
Dispatcher.GuiDispatcher.BeginInvoke(new MethodInvoker(()=>
{
    //some code to be executed in the GUI thread
}), null);

Both Control.Invoke and Control.BeginInvoke methods may accept different delegate types and their parameters. However, this causes a serious performance issue as the main code calling method is Delegate.DynamicInvoke(params object[] args), which in turn uses low-performance reflection. At the same time, for some delegates such as EventHandler, MethodInvoker and WaitCallback the code is called directly. In the time of code execution the delegate is checked for belonging to one of the above types with specified number of parameters, and if it doesn’t – DynamicInvoke() is called.

From practical point of view the synchronization process should look as follows:

    someControl.BeginInvoke(new MethodInvoker(delegate
    {
        //a code here
    }));

For comparison, if custom delegates are used, performance of Invoke call from non-GUI thread equals on the average:

Custom delegate: 25,000 calls per second.
MethodInvoker: 40,000 calls per second.

If Control.Invoke is called from GUI thread that doesn’t count inter-thread synchronization rate and doesn’t have context switches, the results are as follows:

Custom delegate: 150,000 calls per second
MethodInvoker:  1,200,000 calls per second.

The example code is provided below:

    ThreadPool.QueueUserWorkItem(delegate
    {
        int k = 0;

        DateTime dt = DateTime.UtcNow;
        for (int i = 0; i < 10000; ++i)
        {
            //CustomDelegate d = delegate { k++; };
            //Invoke(d, new object[]{EventArgs.Empty});

            Invoke(new MethodInvoker(delegate { k++; }));
        }
        TimeSpan ts = DateTime.UtcNow - dt;

        MessageBox.Show(string.Format("{0} invokes. Perf = {1} call/sec", k, 1000*k/ts.TotalMilliseconds));
    });

Summary. To improve performance it is always better to use MethodInvoker that improves performance by 50% when calling Control.Invoke method from non-GUI thread and tenfold when calling from GUI thread.