.NET: How do I invoke a delegate on a specific thread? (ISynchronizeInvoke, Dispatcher, AsyncOperation, SynchronizationContext, etc.)

Question

Note first of all that this question is not tagged winforms or wpf or anything else GUI-specific. This is intentional, as you will see shortly.

Second, sorry if this question is somewhat long. I try to pull together various bits of information floating around here and there so as to also provide valuable information. My question, however, is right under "What I would like to know".

I'm on a mission to finally understand the various ways offered by .NET to invoke a delegate on a specific thread.

---

What I would like to know:

• I am looking for the most general way possible (that is not Winforms or WPF-specific) to invoke delegates on specific threads.

• Or, phrased differently: I would be interested if, and how, the various ways to do this (such as via WPF's Dispatcher) make use of each other; that is, if there is one common mechanism for cross-thread delegate invocation that's used by all the others.

---

What I know already:

• There's many classes related to this topic; among them:

  • SynchronizationContext (in System.Threading)
    If I had to guess, that would be the most basic one; although I don't understand what exactly it does, nor how it is used.

  • AsyncOperation & AsyncOperationManager (in System.ComponentModel)
    These seem to be wrappers around SynchronizationContext. No clue how to use them.

  • WindowsFormsSynchronizationContext (in System.Windows.Forms)
    A subclass of SynchronizationContext.

  • ISynchronizeInvoke (in System.ComponentModel)
    Used by Windows Forms. (The Control class implements this. If I'd have to guess, I'd say this implementation makes use of WindowsFormsSynchronizationContext.)

  • Dispatcher &DispatcherSynchronizationContext (in System.Windows.Threading)
    Seems like the latter is another subclass of SynchronizationContext, and the former delegates to it.

• Some threads have their own message loop, along with a message queue.

  (The MSDN page About Messages and Message Queues has some introductory background information on how message loops work at the system level, i.e. message queues as the Windows API.)

  I can see how one would implement cross-thread invocation for threads with a message queue. Using the Windows API, you would put a message into a specific thread's message queue via PostThreadMessage that contains an instruction to call some delegate. The message loop — which runs on that thread — will eventually get to that message, and the delegate will be called.

  From what I've read on MSDN, a thread doesn't automatically have its own message queue. A message queue will become available e.g. when a thread has created a window. Without a message queue, it doesn't make sense for a thread to have a message loop.

  So, is cross-thread delegate invocation possible at all when the target thread has no message loop? Let's say, in a .NET console application? (Judging from the answers to this question, I suppose it's indeed impossible with console apps.)

Achernar

Answer 1

Sorry for posting such a long answer. But I thought it worth explaining what exactly is going on.

A-ha! I think I've got it figured out. The most generic way of invoking a delegate on a specific thread indeed seems to be the SynchronizationContext class.

First, the .NET framework does not provide a default means to simply "send" a delegate to any thread such that it'll get executed there immediately. Obviously, this cannot work, because it would mean "interrupting" whatever work that thread would be doing at the time. Therefore, the target thread itself decides how, and when, it will "receive" delegates; that is, this functionality has to be provided by the programmer.

So a target thread needs some way of "receiving" delegates. This can be done in many different ways. One easy mechanism is for the thread to always return to some loop (let's call it the "message loop") where it will look at a queue. It'll work off whatever is in the queue. Windows natively works like this when it comes to UI-related stuff.

In the following, I'll demonstrate how to implement a message queue and a SynchronizationContext for it, as well as a thread with a message loop. Finally, I'll demonstrate how to invoke a delegate on that thread.

---

Example:

Step 1. Let's first create a SynchronizationContext class that'll be used together with the target thread's message queue:

class QueueSyncContext : SynchronizationContext
{
    private readonly ConcurrentQueue<SendOrPostCallback> queue;

    public QueueSyncContext(ConcurrentQueue<SendOrPostCallback> queue)
    {
        this.queue = queue;
    }

    public override void Post(SendOrPostCallback d, object state)
    {
        queue.Enqueue(d);
    }

    // implementation for Send() omitted in this example for simplicity's sake.
}

Basically, this doesn't do more than adding all delegates that are passed in via Post to a user-provided queue. (Post is the method for asynchronous invocations. Send would be for synchronous invocations. I'm omitting the latter for now.)

Step 2. Let's now write the code for a thread Z that waits for delegates d to arrive:

SynchronizationContext syncContextForThreadZ = null;

void MainMethodOfThreadZ()
{
    // this will be used as the thread's message queue:
    var queue = new ConcurrentQueue<PostOrCallDelegate>();

    // set up a synchronization context for our message processing:
    syncContextForThreadZ = new QueueSyncContext(queue);
    SynchronizationContext.SetSynchronizationContext(syncContextForThreadZ);

    // here's the message loop (not efficient, this is for demo purposes only:)
    while (true)
    {
        PostOrCallDelegate d = null;
        if (queue.TryDequeue(out d))
        {
            d.Invoke(null);
        }
    }
}

Step 3. Thread Z needs to be started somewhere:

new Thread(new ThreadStart(MainMethodOfThreadZ)).Start();

Step 4. Finally, back on some other thread A, we want to send a delegate to thread Z:

void SomeMethodOnThreadA()
{
    // thread Z must be up and running before we can send delegates to it:
    while (syncContextForThreadZ == null) ;

    syncContextForThreadZ.Post(_ =>
        {
            Console.WriteLine("This will run on thread Z!");
        },
        null);
}

---

The nice thing about this is that SynchronizationContext works, no matter whether you're in a Windows Forms application, in a WPF application, or in a multi-threaded console application of your own devising. Both Winforms and WPF provide and install suitable SynchronizationContexts for their main/UI thread.

The general procedure for invoking a delegate on a specific thread is the following:

• You must capture the target thread's (Z's) SynchronizationContext, so that you can Send (synchronously) or Post (asynchronously) a delegate to that thread. The way how to do this is to store the synchronization context returned by SynchronizationContext.Current while you're on the target thread Z. (This synchronization context must have previously been registered on/by thread Z.) Then store that reference somewhere where it's accessible by thread A.

• While on thread A, you can use the captured synchronization context to send or post any delegate to thread Z: zSyncContext.Post(_ => { ... }, null);

Achernar

The implementation of QueueSyncContext.Send is incorrect, because it invokes the delegate on the caller's thread. The intent of Send is to block the caller while the delegate runs on the thread represented by the SynchronizationContext. This ensures that the delegate accesses the right thread-local objects, doesn't run at the same time as other delegates invoked via Send or Post (to avoid race conditions), etc. (Note that this doesn't apply to free-threaded sync contexts that e.g., run delegates on the threadpool, but I didn't think this was your intent here.) – Meredithmeredithe

@Bradley: You're correct, and I've removed that implementation from the answer for exactly that reason while you were commenting on it. It would go too far for a simple code example to take care of the necessary synchronization. – Achernar

Nice write-up. Before I discovered this post, I was looking around for an answer to this, and found an example at IDesign; see the item under the ".NET Downloads" section titled "Custom Synchronization Context." By the way, Ch. 16 of Joe Duffy's "Concurrent Programming on Windows" covers every one of the BCL classes you list in your original post in very nice detail. – Naomanaomi

@Andrew, thanks, and thanks for the link to that book. Btw., there is also a fairly good article on Code Project about SynchronizationContext. – Achernar

Answer 2

If you want to support calling a delegate on a thread which doesn't otherwise have a message loop, you have to implement your own, basically.

There's nothing particularly magic about a message loop: it's just like a consumer in a normal producer/consumer pattern. It keeps a queue of things to do (typically events to react to), and it goes through the queue acting accordingly. When there's nothing left to do, it waits until something is placed in the queue.

To put it another way: you can think of a thread with a message loop as a single-thread thread pool.

You can implement this yourself easily enough, including in a console app. Just remember that if the thread is looping round the work queue, it can't be doing something else as well - whereas typically the main thread of execution in a console app is meant to perform a sequence of tasks and then finish.

If you're using .NET 4, it's very easy to implement a producer/consumer queue using the BlockingCollection class.

Ladin

@Jon: OK, let's suppose I now have a thread with a message loop (which, if I understand your answer well, is truly is the one requirement for cross-thread delegate invocation); how would I now invoke a delegate on that particular thread, using the most general mechanism provided by the .NET Framework / BCL? (Would it be sufficient to write my own SynchronizationContext; or would I have to come up with my own solution that has nothing in common with what's already in the BCL?) – Achernar

@stakx: It would depend how you were running the message loop. If you had a simple producer/consumer queue, you could just add the message to the queue. – Ladin

To give a quick reason why I rejected your (helpful) answer in favour of my own: I wasn't worrying so much about message loops as about finding the most general way (BCL class or interface) that .NET provides for invoking a delegate cross-thread. That's why I made that list of classes and interfaces which seem related to the topic in the first place. -- Nevertheless, your answer did give me some valuable insight; namely that message queues really don't have to be complicated. – Achernar