Understanding the Dispatcher Queue

Question

I think I need some help understanding the Dispatcher Queue.

When new work arrives it gets added at the beginning of the dispatcher queue and when the Dispatcher wants to process a working item it gets removed from the beginning.

In more general terms: If there is work it gets stored in a FIFO manner inside the queue and processed as long there is no work left.

The MSDN documentation here is referring to a loop and a frame:

The Dispatcher processes the work item queue in a loop. The loop is referred to as a frame.

But where is a loop in this context ? For me a loop is something that iterates over something and when it reaches the end it starts over again.

And what's the concept of a frame ? According to the MSDN documentation a frame is a punch of working items inside the queue ? If that's true how should the static method Disptatcher.PushFrame() be used ?

And the most interesting question is whether there is any way to get the current state of the queue especially how many items are in the queue.

Does it hold if a method that has been invoked before (and therefor put into the Dispatcher queue) gets executed that it is then removed from the queue immediately or does it last inside for another period of time ?

I know, So many questions :-)

Answer 1

There's very little documentation surrounding the Dispatcher, so you'll have to disassemble around a bit to know about the inner workings.

A dispatcher is basically something which performs work around the application's Message Pump. The one in question sits on top of the windows message loop.

As a consequence, there can only be one application Dispatcher - the global dispatcher object accessible by Application.Current.Dispatcher. Other dispatchers are possible by accessing Dispatcher.CurrentDispatcher, which according to the documentation

Gets the Dispatcher for the thread currently executing and creates a new Dispatcher if one is not already associated with the thread.

However, calling Run on this new dispatcher will be blocking.

When you do a Dispatcher.PushFrame, it pushes an inner execution loop into the Dispatcher - that's the general idea of a frame. Anything that inherits from DispatcherObject such as DispatcherFrame will have its dispatcher set to the current one. We can verify this by looking at its constructor.

private Dispatcher _dispatcher;

protected DispatcherObject()
{
    this._dispatcher = Dispatcher.CurrentDispatcher;
}

Of course, having a simple event loop isn't enough - there are times when you need to subvert the current event loop to force other work to be done. And that's why you have a DispatcherFrame. This is what actually constitutes the event loop. When you push a frame into the Dispatcher, this is what happens:

while (frame.Continue)
        {
            if (!this.GetMessage(ref msg, IntPtr.Zero, 0, 0))
            {
                break;
            }
            this.TranslateAndDispatchMessage(ref msg);
        }

It is in the TranslateAndDispatchMessage that the prioritized queue in the Dispatcher gets evaluated, after a message is taken out.

If an operation takes a long time to run on the dispatcher, it temporarily stops the event loop, and because it doesn't respond to signalling, the application seems like it stops responding.

Here's an article which uses a frame to force the UI to respond by allowing the event loop to run shortly.

As for accessing the queue, as it is, there is no way to know the state of the queue outside of the Dispatcher. This is an internal detail, and it's reasonable that it's not exposed.