The Role of Threaded Clients in a Distributed System

This chapter is the first of two that deal with threading. This chapter looks at the role of threading in the client application. The next chapter discusses how threading can improve the server side. The central focus in this chapter is using threading to improve the performance and responsiveness of a client.

But does multithreading improve performance? It actually depends on the task. If you are writing an intensive number-crunching algorithm that performs several calculations, using threads won't reduce the total time required to complete the operation. In fact, because the separate threads are competing for the CPU and slight overhead is required to switch from thread to thread, a multithreaded approach will probably complete more slowly than a single-threaded solution. (This isn't necessarily true if your computer has more than one CPU, in which case multiple threads might allow Windows to optimize execution by using more than one CPU at the same time. However, relatively few client computers have more than one processor.)

On the other hand, if you have an operation that has some latency, multi­threading can increase performance. If you have to make several XML Web service calls, for example, performing all of these calls at once from separate threads can save some significant time. If you invoke the methods consecutively, you'll spend time waiting for the first method to return and then spend time waiting for the second method to return, and so on. If you call the methods simultaneously, you can collapse your waiting time into one interval (as shown in Figure 6-1).

Figure 6-1. When operations involve waiting, asynchronous calls can dramatically improve performance.

The possible benefits of threading depend on the bottleneck. In the example shown in Figure 6-1, the client is being held back by the speed of its Internet connection. It needs to wait for the request message to be forwarded to its destination (the Web server) and for the response message to be routed back. A similar technique can be used to optimize a network or database call, which also incurs some overhead and entails some waiting. As a rule of thumb, the longer the wait, the more of advantage you can reap by using a multithreaded design.

If your threads are competing for finite resources on the client computer (such as the CPU), however, multithreading won't increase performance. Instead, it will cause all the operations to complete more slowly. In Figure 6-2, for example, the total time taken to complete the operations asynchronously is about the same as the time taken to complete them synchronously. In the asynchronous case, however, both operation A and operation B appear to take the full length of time before completing. In the synchronous case, operation A will complete more quickly. (Operation B will still take the full length of time because it won't be started until operation A ends.)

Figure 6-2. When operations involve a limited resource, asynchronous calls won't improve performance.

Of course, there's another reason to use multithreading. In many cases, particularly in the Internet world, a client uses threading to ensure that the user interface remains responsive. Imagine, for instance, that your application has a Get Info button that triggers a call to an XML Web service. If you don't use threading, the client will have to sit idly by while you download all the information. If you perform the call on a separate thread, however, the client can continue to interact with your user interface, performing different tasks. This might just be a user interface nicety, or it might have a genuinely useful purpose, such as enabling the user to cancel a long-running asynchronous process instead of forcing him to shut down the application. We'll look at an example at the end of this chapter that shows how threading can ensure a responsive client.

The value of threading also depends on the type of application. With a Windows application, multithreading is often used so that your code can ­perform several tasks while interacting with the user. With an ASP.NET application, however, this isn't the case. In an ASP.NET Web page, all the processing happens at once, and the final rendered HTML isn't sent to the client until all your code has finished executing. Therefore, using threading won't make the interface more responsive; it will just divide your tasks into more units of execution. (Of course, you might still use threading to collapse waiting times in certain scenarios. For example, if your ASP.NET Web page code needs to make multiple XML Web service calls, however, you can use threading to make all the calls at once, collapse your waiting time, and possibly return the page to the client a few seconds faster.)

Note

Multithreaded programming isn't always in your best interest. It adds a new level of complexity to client programs and can introduce unusual errors, difficult-to-detect bugs, and other coding nightmares. Quite simply, threading properly is no easy feat. Threads also require additional overhead because the operating system must track and schedule them. If you won't see an obvious benefit from adding threading, don't be afraid to leave it (and the additional locking and synchronization concerns) behind.