| DCOM Explained by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98

Previous | Table of Contents | Next

The use of threads

Threads serve two quite distinct purposes within a distributed application:

  • They can be used to provide support for asynchronous processing
  • They can be used to improve performance

Asynchronous processing support-Normal communication between clients and servers using DCOM is synchronous with the client sending a request and then waiting with its thread blocked until the reply is received. By using the threads service, however, asynchronous communication can be supported—the client spawns a new thread to handle any additional processing while the existing thread waits for the reply.

There are alternative means by which asynchronous processing can be supported. One of these ways has already been described—the Outgoing interface.

Figure 10.2 Asynchronous support

All events sent to outgoing interfaces are by their nature asynchronous because the event is sent to DCOM and server processing can then proceed.

Another way is to use a call back object. In this case, a special call back object is created to handle any replies. Note, however, that the initial reply from the called object still has to be waited for even if it is only an acknowledgment.

Figure 10.3 Using the call back object to support asynchronous processing

We will also see in the chapters on MSMQ and MTS that they offer their own specialized form of support for asynchronous processing. So, there are ways the programmer can use to avoid having to use threads to achieve asynchronous processing. To improve performance, however, the thread service must be used.

Performance improvement-When applications are distributed, many clients may be requesting the same component. If some means of increasing the number of server copies available is not available, the client either has to wait in a queue to be processed (if one exists) or in the worst case, it could be simply turned away. To achieve the highest throughput on a single machine, developers must be provided with a means of duplicating servers on the machine.

Microsoft employs a multithreading rather than a multitasking model to increase the number of available servers. Multitasking would have been an option, but is perhaps less efficient in its use of memory—something Microsoft is perpetually trying to conserve because of their traditional platform base.

Some middleware vendors use multitasking—stating that it is much easier to program (which it is), but they traditionally support environments which use larger machines (not PCs) where memory is not a particular problem.

In DCOM, as the number of clients needing to access a server increases; the server is multithreaded to handle each client in parallel.

Thread creation in basic DCOM is not automatic. Without MTS (which we will be looking at in a later chapter and which does support automatic thread creation) the programmer is responsible for creating his or her own threads. Thus, the programmer will use a special set of interfaces provided within DCOM itself to create new server threads. The programmer also has to control locking. Functions such as CreateThread, ResumeThread, WaitForMultipleObjects, WaitForSingleObject, CreateMutex, and CreateEvent are used to handle threads. The programmer then uses the features supplied with the thread service—mutexes, critical sections, and semaphores to protect access to the data. Basically the developer generally needs to ensure the component is “thread safe.”

With any object-based model, Microsoft had a choice as to what to thread—the server, the object/component, or the method. In DCOM, the developer can “free thread” a component if desired. In free threading, each object invocation may be handled by a separate thread.

Figure 10.4 Each object invocation may be handled by a separate thread

What this means is that one client thread can be communicating with multiple server threads, each one handling a different invocation from that client. At one time, Microsoft restricted a client thread to one server thread; DCOM removed this restriction. Dispatching is handled by the COM library in conjunction with the MS RPC runtime library.

How does Microsoft’s thread service work?

DCOM uses an unusual approach to thread provision. A thread pool, managed by DCOM, is set up for incoming requests. On multiprocessor machines, the thread pool is optimized to the number of available processors. The number of threads in the pool is preallocated by the administrator, but in principle the number of threads in the pool can be as large as the administrator wants—there is no DCOM imposed limit.

In response to a request for a component, DCOM allocates a thread from the pool, calls the component on that thread, and, after the call completes execution, returns the thread to the pool. As requests arrive, the number of actual threads in the pool is increased up to the preallocated maximum number.

In summary

Microsoft bases all their DCOM services upon a multithreading model of processing rather than a multitasking one in order to improve memory usage. Servers and client can be multithreaded, but the programmer must control threads, creating them, removing them, and handling the locking.

It is worth noting that we have avoided going into the types of thread model—apartment and free threads—because we feel this is too low a level for this book, but the type of threads does affect the approach taken by the programmer and to what extent he is supported. The apartment model of threading used for user interfaces provides slightly more support than the free threading model used for all other types of processing.

Previous | Table of Contents | Next