Using Microsoft Visual Basic, you can create multithreaded ActiveX DLLs and EXEs. This can be advantageous in a handful of situations, but multithreading also adds a level of complexity to your code that can be highly unpredictable if you don't know exactly what you're doing. You should approach multithreading with extreme caution. You must have a solid understanding of the conceptual issues before you begin to add multithreaded techniques to your production code. Bad things happen to good programmers who approach multithreading with a casual attitude. This chapter shows you what you need to know and encourages you to think long and hard about whether multithreaded applications are really worth the trouble.
Why would you need multiple threads in an application? Many new programmers think that multithreading is done to make things faster. In most cases, however, the purpose of a secondary thread is to improve responsiveness. When a user is editing a document in Microsoft Word, for example, background tasks such as document repagination and print spooling jobs are conducted on secondary threads. This allows the application to be fully responsive to the user at all times.
Can multithreading ever really speed things up? On a computer with a single processor, usually not. Each additional thread creates more administrative overhead for the system's thread scheduler. The overall throughput of the system actually diminishes as more time is spent switching among threads and less time is spent doing real work. The primary situation in which multiple threads significantly increase the throughput and speed of an application is on a computer with two or more processors.
Earlier versions of Visual Basic had few threading capabilities. Since Visual Basic has been used primarily to create forms-based, single-user applications, this limitation hasn't been overly taxing. Many programmers have found that the DoEvents statement can simulate multithreading to a degree and provide applications with greater responsiveness.
Recently Visual Basic has become popular for building nonvisual, server-side business objects. In a server-side process with many connected clients, threading becomes a much greater concern. The way that a distributed application deals with threading determines whether it can scale up to accommodate a larger user base. If you're creating server-side objects, you should understand what's going on with threading in both Visual Basic and COM.
You must understand what a COM apartment is if you want to master the multithreading techniques available in Visual Basic. However, before you can understand apartments, you must understand the principles of threading in the Win32 API. This chapter begins by explaining how threads are created and managed by the Win32 API. Even though you won't directly apply these Win32 techniques and concepts from within Visual Basic, you must understand them. Everything that COM does with apartments is built on top of the Win32 threading model.