As I mentioned, each program, or process, has by default a single thread. To be more precise, each application domain has its own thread. Application domains, represented by the AppDomain class, and let the programmer provide isolation, security, and unloading boundaries for executing managed code.

A program or process has a single default application domain and the programmer can create additional ones. I mention application domains only because they are relevant to threads. Any thread is by necessity owned by an application domain, the default domain for the default thread, and (for additional threads) the application domain in which the thread was created. Threads are not confined to a single application domain, however, although at any moment a thread executes within a single domain.

A thread in .Net can be either a foreground thread or a background thread. There is only one difference between these two types of thread: a background thread does not keep the managed execution environment running. In practical terms, this means that once all foreground threads have been stopped (a program's default thread is a foreground thread), the system automatically shuts down any remaining background threads.

To create threads in a .Net application, you have three options. Two of them, the managed thread pool and the BackgroundWorker class, are relatively easy to use and can handle the majority of multithreading needs. The one you'll choose depends on the nature of the task to be performed by the thread and the amount of control you need to have. A third method, based on the Thread class, is quite complex; it is not covered here (although it may be the topic of a future series).

The Managed Thread Pool

The managed thread pool, represented by the ThreadPool class, provides an application with a pool of threads that are managed by the system. They are easy to use because you do not have to tend to their management, and they are suitable for many (but not all) tasks for which you might want to create a new thread.

The most important factors to consider when deciding if the ThreadPool class is appropriate for you needs are:

• ThreadPool threads are always background threads and cannot be used if you need a foreground thread.
• ThreadPool threads always have the default priority and cannot be used if you require a different priority.
• ThreadPool threads are not appropriate multiple threads for tasks that will cause the thread to block for long periods of time.
• ThreadPool threads are not appropriate for tasks that need to interact with the user interface.
• ThreadPool threads are not appropriate when you need to give the user the ability to cancel the task before it has completed.

Despite the limitations, this leaves lots of possibilities open for using ThreadPool threads, such as downloading large files, waiting for network responses, and performing time-consuming calculations.

The first step in using a ThreadPool thread is to write the method that performs the work. This method can call other methods, of course, but it is the starting point for the new thread execution. It must take one argument, as shown here:

Shared Sub MyThreadMethod(stateInfo As Object)

' Code to perform task goes here

End Sub

Then you set things in motion by calling the ThreadPool class's QueueUserWorkItem() method. As with all threading-related elements of the Framework, ThreadPool is in the System.Threading namespace. This method has two overloads:

ThreadPool.QueueUserWorkItem(WaitCallback)
ThreadPool.QueueUserWorkItem(WaitCallback, Object)

The first argument is a WaitCallback instance that knows the address of the method to be called. The second optional argument can be used to pass an object that contains data to be used by the method. Thus, for the sample method shown above, you would start a new thread like this:

ThreadPool.QueueUserWorkItem(New WaitCallback(AddressOf MyThreadMethod))

As soon as a thread is available — which will be immediately, except in very usual situations — the method will start executing in the new thread. The thread continues until execution returns from the method, and then it ends. Once such a thread has been started, there is no way to cancel it. There's also no way to monitor progress or detect when it has completed unless code in the thread sets global flags that other parts of the program can check. But remember that the thread pool is best suited for relatively short operations that do not need monitoring.

Ending This Thread

This article has shown you one of the ways to implement multithreading in a .Net application. In the second article, I'll cover another technique that offers you a bit more flexibility.