An experienced Visual Basic programmer who knows how COM apartments work can use certain techniques to reliably exploit multithreaded behavior. You can use multithreading safely and easily in many situations. In other scenarios, multithreading becomes more difficult and hazardous.
Programmers have always been fascinated by things that are cool and complex. This has compromised their ability to distinguish between necessary features and overpriced luxuries. For inexperienced programmers, threads can fall into the latter category. Think of threads as you think of salt. We need a little bit of it to stay alive, but too much can be harmful. Always consider whether the value that threads add to your application is worth the risk and complexity.
If the costs outweigh the benefits, avoid multithreading altogether. For example, you have seen that creating a secondary thread in a form-based application is extremely difficult. On the other hand, it can be extremely valuable because this technique allows you to run background tasks or execute remote methods without locking down the user interface. However, any programmer who's responsible for writing and maintaining this code has to know exactly how Visual Basic uses apartments. Programming at this level is well beyond the capabilities of all but the most experienced Visual Basic programmers.
The most significant need for multithreading exists in a distributed application that runs as a server-side process. If a distributed application has many connected clients, proper threading support is required to achieve reasonable scalability. To scale up to accommodate hundreds of clients, an application must have very sophisticated threading code. The answer to this problem isn't an ActiveX EXE. Instead, Microsoft provides sophisticated thread management in the MTS run-time environment. You distribute your objects in apartment-threaded DLLs and let MTS manage the thread pooling for you. We'll resume our exploration of this important topic in Chapter 9.