Introduction
Let's look at the following scenario: you have an object that should do something asynchronously. However, if the same action is required many times, you want to keep the order of the original calls. In other words, you want the object to keep an internal buffer of calls, and process them sequentially on a separate thread (all in the same thread that is different from the calling thread). We all know this simply as: a message loop.
This could be regarded as a specific case for a 1-thread threadpool. However, since it is a special case, you can make it much simpler than a fully functional threadpool. BTW, if you want a really well-implemented, feature-rich threadpool, you should definitely have a look at Ami Bar's Smart Thread Pool.
How does it work?
All calls are saved in an internal queue. The queue is emptied by one single thread in sequential order (FIFO), and each time an item is extracted from the queue, its corresponding action is executed. The objects in the queue hold a delegate to the method to be invoked and a state object, similar to ThreadPools.
To avoid overfilling the buffer, you can predefine a maximum buffer size. When the buffer reaches that size, any additional message is being dropped, until some free space is available on the buffer (the default size is int.Max).
Where did I find it useful?
I have several places where I have to read messages from a MSMQ queue and do something upon receiving a message. Sometimes, the order of the messages is very important, and I should not start running with one message before the previous ones are completed. Another good example is with various logging mechanisms. With logging, the order of the messages is extremely important. However, you want the thread to return to the caller as soon as possible, in order to diminish the overhead of using logging. So using a message loop, I can put the message to the queue real fast, and log it in the background, hence providing asynchronous sequential logging.
What's in the demo?
The demo is really simple, it just shows you that the messages are indeed processed in the order in which they were added to the queue. As a contrast, you can unmark the line that sends the messages to the thread pool and see the difference.
