Threading and User Interfaces

I'm constantly amazed by the general lack of awareness of threading architectures apparent in many Windows applications and in Windows itself. Why for example does file-copy in Windows copy only a single file at a time and pause all file copying operations every time it needs user input? Why does the user interface become sluggish or freeze up entirely as it is doing other work? Outlook has always been one of the worst offenders here but there are many many other examples that spring to mind.

As we move to a world of hyper-threaded and dual-core architecture CPUs it's more important than ever to get your threading design right.

Here are some general rules on thread design that I find helpful:

1. You should never put anything that will take more than a few milliseconds on the UI thread in any Windows application! Anything that will take longer than this should be passed off to a worker thread, and then an asynchronous event used to pass information back to the UI thread as the work progresses in the background. So, for example, don't try to load an image from a disk on the UI thread (it might be on a slow CD drive or across a network); don't call a web method; don't access any databases; don't try to populate a large datagrid or listview. Don't even try to create all your worker threads using the UI thread! Even that can slow down your application startup experience.

2. Consider putting nearly all of your startup code on its own thread. In many cases, by doing this you can eliminate the need for a splash screen. The application appears to start immediately and then, over the next few seconds, a worker thread does all the background work it needs to load the application state, to create all of the other worker threads that will be needed and to load any graphics needed by the UI thread.

3. Worker threads should never run at Normal priority, they should [nearly]always run at a lower priority than the UI thread. See rule 7.

4. Even on a single processor, hyperthreaded machine, don't limit yourself to two worker threads. If you have more work that can be done simultaneously, add more threads than you have physical (or logical in the case of HT) CPUs. Threads nearly always have other work to do besides pure computation and as soon as they hit any I/O operations they will yield the CPU to other waiting threads. If you have 4 threads, each doing mainly computation you'll still find a performance increase over 2 threads.

5. Don't add too many threads. Thrashing between threads unnecessarily is a waste of CPU time and more importantly in many situations, memory bandwidth. It also increases your total memory footprint which in a .NET application can easily be the limiting factor.

Ideal number of threads = minimum of

• # threads that can fit in memory,
• # threads that can reasonably do work in parallel,
• # threads that will try to use just slightly over 100% of available CPU resources

6. Never, ever poll. Polling is a complete waste of energy - both in programming terms and in terms of the environment. Your thread should go completely to sleep after it has done its work and wake up only after some preset interval when the next work item is due, or when signalled by another thread (probably the UI thread) telling it that it has more work to do, or when an I/O operation completes.

7. Thread priority should [almost] never be used to get your program to work, it should only be used to make it work better. As you create your multi-threaded application you will find that some worker-thread tasks are just not as important as others. A worker-thread loading an image to display in the user interface within the next 300ms probably deserves a higher priority than a worker thread trying to find pi to the next million decimal places. But as mentioned above, none of these is ever as important as keeping the UI responsive so except in the case where you are trying to play audio or video or some other time critical task that simply does not work right if it doesn't execute at precisely the right moment, always put your worker threads on a lower priority than you UI thread.

Summary:

1. Higher-than-normal priority: Time critical threads (playing audio or video, controlling a nuclear reactor, logging data from a device with a limited buffer, sending data to a device with no flow control, ...)
2. Normal priority: The UI thread and no other threads.
3. Below normal, all the way down: All worker threads accessing any I/O devices, performing any asynchronous operations like database access or web download. All worker threads performing any serious computation.

At some later date I'll write up my thoughts on some good patterns for worker threads. These typically wait to be signalled by the UI thread to do some work, or for a set time interval to expire. They maintain a work queue, or they share a work queue with other threads doing similar work. They run for a while, signal the UI thread if necessary using an event (which is then Invoked back on the UI thread) and then loop to work on the next work item in the queue. If the next work item has a time associated with it, they sleep until that time or until woken with some more work to do. They may also add more work to their own work queues or to the work queues of other worker threads.