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 :-)

Uroscopy

First question: why? Why do you want to anything with Dispatcher? Typically, Dispatcher is simply the "message pump" for a WPF process. It handles all the messages/events/commands through the WPF UI to the application code (e.g. mouse movement, clicks, etc.) When the applications Run method is invoked, it calls PushFrame to start that loop. You can't start another one for the same thread; and Dispatcher is meant to processing UI work. – Barbed

Did you read about the threading model? – Garey

It is a standard solution to the producer-consumer problem: en.wikipedia.org/wiki/Producer-consumer_problem – Fulbright

When the dispatcher adds/removes items at/from the beginning, it's called LIFO. So basically it's a stack. – Dayton

"When new work arrives it gets added at the beginning of the dispatcher queue" ... then it's not a queue. Are you sure that's not a typo? – Linseed

The queue if FIFO. From learn.microsoft.com/en-us/windows/win32/winmsg/…: "With the exception of the WM_PAINT message, the WM_TIMER message, and the WM_QUIT message, the system always posts messages at the end of a message queue. This ensures that a window receives its input messages in the proper first in, first out (FIFO) sequence" – Gusto

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.

Patsy

Thank you very much for your detailed answer (and sorry for the delay) – Uroscopy

"As a consequence, there can only be one Dispatcher per application.". <= That isn't true, dispatcher instances will be bound on threads. See summary of the Dispatcher.CurrentDispatcher: "Gets the for the thread currently executing and creates a new if one is not already associated with the thread." You can imagine the Dispatcher as an extension to the messagepump, the extension enables to execute delegates instead of only handling message codes. – Clansman

"It is in the TranslateAndDispatchMessage that the prioritized queue in the Dispatcher gets evaluated, an operation is taken out and executed." -- No, obviously not; that's what GetMessage does. – Ptolemy

@JeroenvanLangen Corrected. Please review. – Patsy

@JimBalter Thanks, I've changed the wording for clarity. – Patsy