Using multiple threads in a program, called multithreading, or just threading, creates program overhead and additional program complexity. For example

In spite of these considerations, the benefits of threading can far outweigh its costs, as long as it is used wisely—and not overused. For example, you've already seen that on a multiprocessor system, if the different threads can be placed on different processors, it can result in a much more efficient execution.

To help alleviate some of the costs associated with creating and destroying threads, the CLR maintains a thread pool for each process. Initially, a process's thread pool is empty, but after a thread is created and used by a process, and the thread completes its execution, it is not destroyed, but instead added to the process's thread pool. Later, if the process needs another thread, the CLR recycles one from the pool, saving a significant amount of time.

Another common example where multithreading is crucial is in graphical user interface (GUI) programming, where the user expects a quick response any time he or she clicks on a button or uses the keyboard. In this case, if the program needs to perform an operation that is going to take any appreciable time, it must perform that operation on another thread, leaving the main thread available to respond to the user's input. It would be totally unacceptable to have the program unresponsive during that time.

Although multithreading is conceptually easy, getting all the details right can be frustratingly difficult on nontrivial programs. The areas that need to be considered are the following:

The System.Threading namespace contains classes and types that you can use to build complex multithreaded systems. These include the Thread class itself, and classes such as Mutex, Semaphore, and Monitor, which are used to synchronize resource usage. The use, complexities, and nuances of this tricky subject are beyond the scope of this text, and you'd be better advised to settle down with an in-depth book on the subject.

You can, however, add very powerful multithreading to your programs through two simple techniques—asynchronous delegates and timers—which I will cover in the rest of this chapter. For most programs, these are probably the only techniques you will need.

Now that you understand the BeginInvoke and EndInvoke delegate methods, we can look at the asynchronous programming patterns. The first one we'll look at is the wait-until-done pattern. In this pattern, the initial thread initiates an asynchronous method call, does some additional processing, and then stops and waits until the spawned thread finishes. It is summarized as follows:

IAsyncResult iar = del.BeginInvoke( 3, 5, null, null );
        // Do additional work in the calling thread, while the method
        // is being executed asynchronously in the spawned thread.
        ...
   long result = del.EndInvoke( iar );

The following code shows a full example of this pattern. This code uses the Sleep method of the Thread class to suspend itself for 100 milliseconds (1/10 of a second). The Thread class is in the System.Threading namespace.

using System.Threading;                         // For Thread.Sleep()
      ...
   delegate long MyDel( int first, int second );   // Declare delegate type

   class Program
   {
      static long Sum(int x, int y)                // Declare method for async
      {
         Console.WriteLine("                       Inside Sum");
         Thread.Sleep(100);

         return x + y;
      }

static void Main( )
      {
         MyDel del = new MyDel(Sum);

         Console.WriteLine( "Before BeginInvoke" );
         IAsyncResult iar = del.BeginInvoke(3, 5, null, null); // Start async
         Console.WriteLine( "After  BeginInvoke" );

         Console.WriteLine( "Doing stuff" );

         long result = del.EndInvoke( iar );    // Wait for end and get result
         Console.WriteLine( "After  EndInvoke: {0}", result );
      }
   }

This code produces the following output:

Before BeginInvoke
After  BeginInvoke
Doing stuff
                      Inside Sum

After  EndInvoke: 8

Now that you've seen BeginInvoke and EndInvoke in action in their simplest forms, it's time to take a closer look at IAsyncResult, which is an integral part of using these methods.

BeginInvoke returns a reference to an IAsyncResult interface that is inside a class object of type AsyncResult. The AsyncResult class represents the state of the asynchronous method. Figure 22-2 shows a representation of some of the important parts of the class. The important things to know about the class are the following:

Figure 22-2. An AsyncResult class object

In the polling pattern, the initial thread initiates an asynchronous method call, does some additional processing, and then uses the IsCompleted method of the IAsyncResult object to check periodically whether the spawned thread has completed. If the asynchronous method has completed, the initial thread calls EndInvoke and continues on. Otherwise, it does some additional processing and checks again later. The "processing" in this case just consists of counting from 0 to 10,000,000.

This code produces the following output:

After BeginInvoke
Not Done
                 Inside Sum
Not Done
Not Done
Done
Result: 8

In the previous two patterns, wait-until-done and polling, the initial thread continues on with its flow of control only after it knows that the spawned thread has completed. It then retrieves the results and continues.

The callback pattern is different in that once the initial thread spawns the asynchronous method, it goes on its way without synchronizing with it again. When the asynchronous method call completes, the system invokes a user-supplied method to handle its results, and to call the delegate's EndInvoke method. This user-defined method is called a callback method, or just callback.

The two extra parameters at the end of the BeginInvoke parameter list are used with the callback method as follows:

The Callback Method

The signature and return type of the callback method must be of the form described by the AsyncCallback delegate type. This form requires that the method take a single parameter of type IAsyncResult and have a void return type, as shown here:

void AsyncCallback( IAsyncResult iar )

There are several ways you can supply the callback method to the BeginInvoke method. Since the callback parameter in BeginInvoke is a delegate of type AsyncCallback, you can supply it as a delegate, as shown in the first code statement that follows. Or you can just supply the name of the callback method and let the compiler create the delegate for you. Both forms are semantically equivalent.

The second BeginInvoke parameter is used to send an object to the callback method. It can be an object of any type, but the parameter is of type object, so inside the callback method you will have to cast it to the correct type.

Calling EndInvoke Inside the Callback Method

Inside the callback method, your code should call the delegate's EndInvoke method and take care of handling the output results of the asynchronous method execution. To call the delegate's EndInvoke method, though, you need a reference to the delegate object, which is in the initial thread—not here in the spawned thread.

If you're not using BeginInvoke's state parameter for anything else, you can use it to send the delegate reference to the callback method, as shown here:

Otherwise, you can extract the delegate's reference from the IAsyncResult object sent into the method as the parameter. This is shown in the following code and illustrated in Figure 22-3.

• The single parameter to the callback method is a reference to the IAsyncResult interface of the asynchronous method that has just completed. Remember that the IAsyncResult interface object is inside the AsyncResult class object.

• Although the IAsyncResult interface doesn't have a reference to the delegate object, the AsyncResult class object enclosing it does have a reference to the delegate object. So the first line inside the example method body gets a reference to the class object by casting the interface reference to the class type. Variable ar now has a reference to the class object.

• With the reference to the class object, you can now call the AsyncDelegate property of the class object and cast it to the appropriate delegate type. This gives you the delegate reference, which you can then use to call EndInvoke.

using System.Runtime.Remoting.Messaging;     // Contains AsyncResult class

void CallWhenDone( IAsyncResult iar )
{
   AsyncResult ar = (AsyncResult) iar;       // Get class object reference
   MyDel del = (MyDel) ar.AsyncDelegate;     // Get reference to delegate

   long Sum = del.EndInvoke( iar );          // Call EndInvoke
      ...
}

Figure 22-3. Extracting the delegate's reference inside the callback method

The following code puts it all together, and is an example of using the callback pattern.

using System.Runtime.Remoting.Messaging;  // To access the AsyncResult type
      ...
   delegate long MyDel(int first, int second);

   class Program {
      static long Sum(int x, int y)
      {
         Console.WriteLine("                         Inside Sum");
         Thread.Sleep(100);
         return x + y;
      }

      static void CallWhenDone(IAsyncResult iar) {
         Console.WriteLine("                         Inside CallWhenDone.");
         AsyncResult ar = (AsyncResult) iar;
         MyDel del = (MyDel)ar.AsyncDelegate;

         long result = del.EndInvoke(iar);
         Console.WriteLine
            ("                         The result is: {0}.", result);
      }

      static void Main() {
         MyDel del = new MyDel(Sum);

         Console.WriteLine("Before BeginInvoke");
         IAsyncResult iar =
            del.BeginInvoke(3, 5, new AsyncCallback(CallWhenDone), null);

         Console.WriteLine("Doing more work in Main.");
         Thread.Sleep(500);
         Console.WriteLine("Done with Main. Exiting.");
      }
   }

This code produces the following output:

Before BeginInvoke
Doing more work in Main.
                        Inside Sum
                        Inside CallWhenDone.
                        The result is: 8.

Done with Main. Exiting.