Threading 101: What is a Dispatcher?

Question

Once upon a time, I remembered this stuff by heart. Over time, my understanding has diluted and I mean to refresh it.

As I recall, any so called single threaded application has two threads:

a) the primary thread that has a pointer to the main or DllMain entry points; and

b) For applications that have some UI, a UI thread, a.k.a the secondary thread, on which the WndProc runs, i.e. the thread that executes the WndProc that recieves messages that Windows posts to it. In short, the thread that executes the Windows message loop.

For UI apps, the primary thread is in a blocking state waiting for messages from Windows. When it recieves them, it queues them up and dispatches them to the message loop (WndProc) and the UI thread gets kick started.

As per my understanding, the primary thread, which is in a blocking state, is this:

C++

while(getmessage(/* args &msg, etc. */))
{
    translatemessage(&msg, 0, 0);
    dispatchmessage(&msg, 0, 0);
}

C# or VB.NET WinForms apps:

Application.Run( new System.Windows.Forms() );

Is this what they call the Dispatcher?

My questions are:

a) Is my above understanding correct?

b) What in the name of hell is the Dispatcher?

c) Point me to a resource where I can get a better understanding of threads from a Windows/Win32 perspective and then tie it up with high level languages like C#. Petzold is sparing in his discussion on the subject in his epic work.

Although I believe I have it somewhat right, a confirmation will be relieving.

Answer 1

It depends on what you consider the primary thread. Most UI frameworks will have an event handler thread that sits mostly idle, waiting for low level events. When an event occurs this thread gets a lock on the event queue, and adds the events there. This is hardly what I'd consider the primary thread, though.

In general a dispatcher takes some events and, based on their content or type sends (dispatches, if you will) them to another chunk of code (often in another thread, but not always). In this sense the event handler thread itself is a simple dispatcher. On the other end of the queue, the framework typically provides another dispatcher that will take events off of the queue. For instance, sending mouse events to mouse listeners, keyboard events to keyboard listeners etc.

Edit:

A simple dispatcher may look like this:

class Event{
   public:
   EventType type; //Probably an enum
   String data; //Event data
};

class Dispatcher{
   public:
   ...

   dispatch(Event event)
   {
      switch(event.type)
      {
         case FooEvent:
            foo(event.data);
            break;
            ...
       }
   };

Most people I've met use "dispatcher" to describe something that's more than just a simple passthrough. In this case, it performs different actions based on a type variable which is consistent with most of the dispatchers I've seen. Often the switch is replaced with polymorphism, but switch makes it clearer what's going on for an example.