Summary
This chapter has given you a flavor for the services that the CLR offers with regards to threading. This chapter has really been a showcase for the kinds of tasks that the CLR allows you to do. In closing, following are some tips and advice on multithreaded applications:
Benchmark—Before starting any multithreaded application, make sure you are aware of the resources that are involved. Spinning many threads might actually degrade your application performance. Consider the ThreadPool. Many of the performance gains that come from using this class are because handing out Threads to perform work is so miserable as compared to an application that starts up 100 or so Threads, where each Thread must synchronize with the others and a context switch must occur just to make sure that all of the Threads will be able to run.
Understand—Understand that a multithreaded application requires time and effort to get it right. When it is wrong, it is either difficult to find out why, or it causes big problems with the rest of the applications that are running on your machine. It took a long time to develop the code samples in this chapter.
Increase Responsiveness—If this is a requirement of your application, then using Threads might be your answer. I remember doing a graphics application once. I found that if I could lock up the application for a brief period of time, the operation performed significantly faster. This argument did not win too many people over because the users of the application required some sort of feedback that the operation was still occurring. Even though putting up a “Working…” message with some progress indication or putting up a hourglass made the operation complete as much as 50 to 70% slower, it became a requirement because users hate to be in the dark.
Better Utilization of CPU—Another application that I developed involved transferring large (2048 × 2048 × 8) images. Most of these transfers were done directly from disk to memory or disk to network with little CPU involvement. These transfers were excellent candidates to be put into a background thread while the foreground actually used the CPU do other things. One of the challenges of using higher speed processors and even multiprocessor machines is to keep the CPU(s) busy. Making the CPU wait in an idle state while something else is being done is a waste of the CPU.
Simplified Design—Being able to isolate specific functionality to that performed by a Thread goes a long way toward simplifying the overall design of the application. If it is known that this Thread only performs a specific function, then where do you go when that function goes bad? A properly designed multithreaded application seems to be naturally object oriented.