Threading in the COM Era

A future version of COM+ will likely address some of the performance limitations of the STA. Currently, if you want COM to serialize access to your objects automatically, you must put them in single-threaded apartments. This has the desired effect of ensuring that all calls to your object are serialized. This practice also has the potentially costly effect of forcing a thread to be dedicated to servicing those calls for the lifetime of the process, rather than simply using an RPC thread borrowed from the RPC thread pool. Microsoft is now working on an enhanced model for concurrency management that has the working name activity threading, or worker threading. Like today's STA-based objects, activity-threaded objects don't need to worry about concurrent access. However, unlike today's STA-based objects, activity-threaded objects don't require a dedicated thread. Instead, the RPC layer can directly dispatch calls to objects using an arbitrary thread borrowed from the RPC thread pool. The RPC layer will track activitywide locks and block any incoming method requests until all previous calls have completed.

While the locking in the activity-threaded model will still protect your objects from concurrent access, it will provide a faster and more scalable architecture. Today's STA-based model has limited scalability because every new STA requires a dedicated thread to service incoming calls. Because COM+ activities won't require dedicated threads, creating hundreds or thousands of activities will be far more acceptable than creating the same number of STAs today. The good news for Visual Basic programmers is that you probably won't have to do anything differently when the activity model becomes available. (Actually, it's available today in MTS, but the current implementation pins activities to STA threads.)

The code you write today for an STA should not behave any differently when COM+'s new activity threading implementation ships later this century. Your Visual Basic objects will simply run faster and be more responsive. That's the good news. The bad news is that your objects will not be able to take advantage of this new threading implementation until the Visual Basic team modifies both its run-time layer and its compiler to provide support for this new model. As mentioned earlier in this chapter, every component created by Visual Basic today has thread affinity. All Visual Basic objects rely on data that's kept in thread-local storage. This means that a Visual Basic object can be accessed only by the thread that created it. Objects with thread affinity won't be able to take advantage of this new model.