Background Threads
There is still a lot missing from the state diagram (see below). Specifically, what happens when you Suspend(), Wait(), Join(), Sleep(), Abort() a background thread. I'm not going to confuse the diagram to explain these new states. Rather, let me explain that a thread is either a background thread or a foreground thread. Actions on a background thread are equivalent to actions on a foreground thread, except in one respect, which I will explain in the next paragraph. So, if you attempt to suspend a running background thread, then it will move to the SuspendRequested state, then to the Suspended state and finally back to the Background state, in the same manner as a foreground thread.
The difference between a background thread and a foreground thread is pretty simple. When the last foreground thread of a process is stopped, then the process terminates. There could be zero, 1 or an infinite number of background threads and they have no vote in whether a process terminates or not. So when the last foreground thread stops, then all background threads are also stopped and the process is stopped. I've seen quite a few .NET programmers incorrectly use the background thread to mean any thread created using the Thread constructor. The terminology is therefore getting very confusing. The correct meaning of background thread in .NET framework is a thread that does not have impact on whether a process is terminated.
Thread Safe Objects and Types
Here's a rather interesting tidbit of news. Many of the .NET objects and types are thread-safe. The first time I heard that I was rather confused at what it could mean. Does this mean an increment (++) operation on a C# integer is atomic? I put together a small piece of C# code that launched a thousand threads and incremented and decremented one integer a million times per thread. I structured the code to swap the threads like mad to try and create a race condition that would invalidate the operations on the integer. I was unsuccessful in generating incorrect results. So, I assume the operation is atomic. But I don't have any proof (beyond proof-by-example) that it is an atomic operation.
Interlocked
Throughout this article, I have written code that assumes that some operations on C# objects and types are atomic. I would never suggest writing such code in a production environment. In such an environment, you will have to fall back onto our old InterlockedIncrement and InterlockedDecrement friends. In C#, these are in the System.Threading.Interlocked class. The class has two static methods Interlocked.Increment and Interlocked.Decrement. Use them well.
Conclusion
I started this trek into .NET threads for one reason. I wanted to evaluate them as a possible alternative for servers that require a lot of thread programming. What I found was that .NET's Threading namespace is by far the easiest way to write applications that require a lot of thread programming. I didn't find any performance problems with the .NET threads, but neither did I find them any faster than other thread libraries available in C++ or Java threads.
Comments