Basic thread management tools
Having provided ample warning and set the stage for when and when not to use multiple threads, I will now describe some of the tools you have at your disposal if you choose to do so. Thread
The .NET libraries provide an object called System.Threading.Thread, which represents a single thread of execution. You can start a thread, seeking to accomplish a task in that thread while the current thread continues. This would be useful for an application that needed to print a document or save a large file but wanted to acknowledge the user's request and return control to the user. We demonstrate this mechanism in Listing A.We first create a method, SayHello, that does what we want to accomplish. Its signature must match that of the System.Threading.ThreadStart delegate. Note the Thread.Sleep(int numMillisecs) call in the SayHello method. This is a useful construct and will appear often in these samples. In the Main routine, we create a new thread with a ThreadStart delegate made from the SayHello method, and call Start on that thread. The thread we created is started, and our main thread continues on to completion in this example. Many times, you will have a slightly different task to perform in each thread and will want to pass each thread a parameter of some sort to differentiate its task from that of the others. While there are several reasonable ways of doing this, the most straightforward is to create a Task object that holds the thread, the unique parameter, and the work method that provides the ThreadStart delegate. From the work method, you can read the supplied parameter, as it is a member of the Task object and is therefore unique to that thread. By making the thread a public field, you have full access to all the thread's members without having to write additional wrapper code. See Listing B for an example of this technique.You can even provide a return value of sorts from the Task object by defining a field in the task to hold it, setting the value before the thread completes, and reading it from the thread that started the task after the task completes. You can pause one thread, waiting for other threads to complete what they are doing. You might do this when you want to collect return values as described above or when you spread a database update across three separate threads but don't want to proceed until all threads are done. This technique is shown in Listing C.Here, we build on the code from Listing A. This time, we launch two threads, each with the same task as before. Following the calling of both threads' Start() methods, though, we call their Join() methods. Calling Join() on a thread causes the calling thread to pause execution until the called thread has completed. So the thread1.Start() method causes the main thread to pause until thread1 has completed. We then do the same thing to thread2. As a result, the main thread does not complete until both thread1 and thread2 have completed. Here are two parting thoughts on this example. First, a thread may not call Join on another thread until that thread has been started. Second, there are two more forms of Join that allow specification of a timeout after which the calling thread will continue even if the called thread is still running. Computer science frequently employs the concept of a watchdog -- an entity whose responsibility is to ensure the correct function, or handling of incorrect functions, in another entity. A common pattern is the watchdog timer, usually responsible for making sure that another task completes in a reasonable time. Listing D shows a simple mechanism for implementing a watchdog timer.After thread1 is started, we join with it, but provide a 10-second timeout. Since thread1 has a 15-second pause built in, it will still be alive when the join expires. The main thread tests thread1.IsAlive and, if it's still alive, terminates the thread.