Daniel Appleman
Have you noticed that Dan has avoided discussing multi-threading in VB5? The reason is simple: He didn't think it was particularly safe to create multi-threaded applications with the original version of VB5. But now that Service Pack 2 is available, it's a different story.
Several people have recently asked me how to create multiple threads in VB5 applications. Some have mentioned the CreateThread API and wondered why I didn't discuss it in my Win32 API book. Well, I'll have a few things to say about the CreateThread API later. You see, I believe it's my responsibility to address not only what you can do with VB, but what you should do as well-and the CreateThread API opens a nest of problems that programmers should face with trepidation, if not outright terror. For the past couple of months I've been answering VB threading inquiries with a cryptic "just wait." I was using the beta version of the new VB Service Pack 2 (SP2), so I knew what was coming. This update to VB5 allows you to create multi-threaded VB5 applications safely.
Now, if you aren't familiar with multi-threading, this column isn't going to make much sense to you. One good source of information is Chapter 14 of my book Developing ActiveX Components with Visual Basic 5.0: A Guide to the Perplexed. This article assumes that you're familiar with multi-threading as it was implemented in VB5.
What a difference a few dialog controls make
In the original VB5, the multi-threading capabilities of an ActiveX server were set in the Project Properties (General) dialog box. This dialog box included a check box titled "Unattended Execution" and two option buttons: one marked "Thread per object," the other "Thread Pool," with the number of threads specified in a text box.
The "Unattended Execution" check box first prevented the server from using any user interface elements such as forms or message boxes. This was the first requirement for multi-threading with VB, because the VB forms engine was not thread-safe. VB uses the so-called "apartment model" of multi-threading, in which all of your components' global variables are thread-specific. In other words, VB makes a separate copy of all of your global variables for each thread. This eliminates most shared memory and synchronization problems, making apartment-model multi-threading relatively safe and easy to use. But because VB5 could not isolate form level variables among threads, it required that multi-threading servers have no user interface elements.
With VB5 SP2, Microsoft figured out how to isolate forms between threads, extending the forms engine to run in the apartment model as well. The "Unattended Execution" check box is still there, but now it's completely independent of the server's multi-threading capabilities.
The multi-threading options are selected in two ways:
In other words, setting Unattended Execution has nothing to do with multi-threading.
The impact of this change on DLL servers is both profound and trivial at the same time. Profound, in that ActiveX DLL servers can now include forms and, more importantly, that ActiveX controls can be marked for apartment-model multi-threading-allowing them to run more efficiently on multi-threading clients such as Internet Explorer. Trivial, in that this requires virtually no effort on the part of the programmer besides changing a combo box option and testing the server using a multi-threading client.
The impact of this change on EXE servers is really limited to one small but crucial area. For most servers there will be no change at all-adding forms to EXE servers that are accessed from other applications is generally pointless. But this change does allow you to create true multi-threading clients using VB. For the rest of this article, we'll explore some of the subtleties involved in doing this.
Multi-threading clients Q&A
Implementing multi-threaded clients using VB5 SP2 raises a number of interesting questions. Rather than simply showing you the answers and resulting code, I've decided to illustrate the techniques involved by using a question-and-answer format, where the questions are ones that I asked myself when first starting out. Keep in mind that we're talking about some very new capabilities in VB, so I haven't had much time to work with them. I won't promise that these are the best possible answers-only that they work. I'll try to suggest other possible solutions along the way as well.
Which threading model should I use?
This is an easy one. A multi-threading client application must be created as an ActiveX EXE server. It's the only model that supports the creation of objects on their own threads. Set the threading option to "Thread per object."
How can I make an ActiveX EXE server behave like a standalone application?
Nothing has changed from the original VB5. You'll need to create a module that contains a Sub Main and set Sub Main as the startup object. Then you'll look at the App.StartMode property-if it's vbSModeStandalone, the server was started as a standalone program and you can show the main form. Once the main form is shown, the server will not terminate until the form is closed and terminated.
If App.StartMode = vbSModeStandalone Then
frmMain.Show
End If
Wait-I have some objects that I don't want to be created in their own threads!
Your application will probably have many objects, only one or two of which you'd want to run in their own thread. Fortunately, VB makes it easy to control which thread an object is created in. Say you have an object called "clsBackground" in a server called ThreadTest1. The following code will create the object in a new thread:
Dim s As clsBackground
Set s = CreateObject("ThreadTest1.clsBackground")
The following code will create the object in the current thread:
Dim s As clsBackground
Set s = New clsBackground
You must use the CreateObject function to create an object in its own thread.
How can I prevent other applications from accessing my public objects?
One of the side effects of this approach to multi-threading is that your application must publicly expose the objects that you wish to run in their own threads. But you probably won't want other applications to access those objects. Disabling an object is easy-you can raise an error during its Initialize event and otherwise disable its operation. Make the termination as ugly as you'd like-nobody is supposed to access that object externally in the first place.
The trick is knowing when the object has been created within your own application.
The solution lies again in the nature of apartment-model threading. Every time a thread is created, the application's Sub Main function is called; this means that you can look at the App.StartMode property and determine whether the thread was started externally. You can then set a global flag (which, of course, is specific to that thread, so it won't interfere with other objects) so that the object will know during its Initialize event whether or not it should enable itself. An example of this is shown in the following code from the code module:
Public BlockLoad As Boolean
Public Sub Main()
If App.StartMode <> vbSModeStandalone Then
BlockLoad = True
Exit Sub
End If
…. Do other initialization here
End If
And this code in the class module:
Private Sub Class_Initialize()
If BlockLoad Then
Err.Raise vbObjectError + 1000, "clsBackground",_
"Can't initialize object"
Else
f.Show
End If
End Sub
You'll need to do this with every public class that you don't want other applications to access.
How can I tell whether Sub Main is being called due to an initial program execution or the start of a new thread?
The first time Sub Main is called, it will be due to the initial launch of a program. But Sub Main will be called again for each new thread. At first glance, you might think to use a global variable to flag whether this is the first call or not, but remember-global variables are thread-specific when using apartment-model threading. One possible approach is shown in the following code:
Private Declare Function FindWindow Lib "user32" _
Alias "FindWindowA" (ByVal lpClassName As String,_
ByVal lpWindowName As String) As Long
Private Declare Function GetWindowThreadProcessId _
Lib "user32" (ByVal hwnd As Long, lpdwProcessId As _
Long) As Long
Private Declare Function GetCurrentProcessId Lib _
"kernel32" () As Long
Public BlockLoad As Boolean
Public Sub Main()
Dim pid As Long
Dim OtherWnd As Long
If App.StartMode <> vbSModeStandalone Then
BlockLoad = True
Exit Sub
End If
If App.PrevInstance = True Then
MsgBox "Can only run one instance of this app"
Exit Sub
End If
' Is the main window already up?
OtherWnd = FindWindow(vbNullString, "Foreground _
Form")
If OtherWnd <> 0 Then
' Make sure it's the same process - don't want
' to interfere with others
Call GetWindowThreadProcessId(OtherWnd, pid)
If pid = GetCurrentProcessId() Then
' Main window is up in the same process,
' so exit
Exit Sub
End If
End If
frmMain.Show ' Show the main window
End Sub
The server loads the main application form the first time it's called. During subsequent calls, the Sub Main function checks to see whether the main form exists by looking for a window with the correct caption that belongs to the same process. Actually, this code is flawed in that it only checks the first window with the specified caption. If you have another application that uses the same window caption, this code might fail. A better solution would be to enumerate all of the top-level windows looking for one with the correct characteristics. Enumeration techniques can be found in Chapter 5 of my Visual Basic 5.0 Programmer's Guide to the Win32 API. If you used the enumeration approach, you could also change the application to allow more than one instance to run at a time. The single instance limitation is placed here because you can't predict which server will implement a particular object if you have more than one server running.
The preceding code combines the techniques described earlier to demonstrate a fairly complete Sub Main implementation. The missing piece of the puzzle is the background class, whose implementation code is shown here:
Dim f As New frmBackground
Private Sub Class_Initialize()
If BlockLoad Then
Err.Raise vbObjectError + 1000, "clsBackground",_
"Can't initialize object"
Else
f.Show
End If
End Sub
This example demonstrates the creation of a form in its own thread. The class simply shows an instance of the form. The Class_Initialize event is already running in the new thread, so the New and Show operations will create the form in this thread as well.
Are there other ways to communicate between apartments?
There are lots of ways to communicate between apartments, all using various API techniques. You can use Windows synchronization objects such as mutexes, semaphores, and events. You can use memory-mapped files to share memory between apartments. You can have your main thread pass object references to the other threads-VB will correctly create proxies for the objects and marshal data between them. I won't go into details here, but don't be surprised if it shows up as the topic of a future column.
Should you create multi-threading applications in the first place?
Offhand, I can think of two reasons why you'd want to create a multi-threading application:
I expect the first of these options to be more common. You shouldn't use a form in a separate thread unless your application's design provides a compelling reason to do so.
Now show me an example!
The ThreadTest1 example is a very simple multi-threaded client. The main window has a button that allows you to display the background forms in their own threads using the following code:
Private Sub frmForeground_Click()
Dim s As clsBackground
Set s = CreateObject("ThreadTest1.clsBackground")
End Sub
Each background form has a button that starts a very long loop operation, as follows:
Private Sub Command1_Click()
Dim l&
For l = 1 To 10000
Label2.Caption = Str$(l)
Label2.Refresh
Next l
End Sub
Each form also has a label control on which it displays its current thread identifier. Try running the program first in VB (be sure the project startup setting is StandAlone). You'll see that each form runs in the same thread, and that a long operation on one form blocks the operation of all the others. The forms and objects exist in a single thread because the VB environment itself doesn't support multi-threading.
Now compile it to an executable and try running the executable. You'll see that each form runs in its own thread, and that a long operation on one form doesn't interfere with the others.
What about the CreateThread API?
You've seen how VB5 can now be used to create true multi-threaded applications. But if you've been reading other industry publications, you might be wondering why I haven't discussed the use of the CreateThread API with VB. Well, I've seen those articles, and I've done quite a bit of work with the CreateThread API-and I have a lot to say about the subject. You see, the CreateThread API can be used effectively from VB-but only with great care and only by observing certain precautions that seem to have been forgotten in many of the discussions on the subject.
You can find out more on this topic, because this month's column also includes a two-for-one special. A feature article that I've written about using the CreateThread API from VB called "A Thread to Visual Basic" can be found at http://www.desaware.com/thread.htm. You'll need to enter the code VBDV10 to view the article (the article is free-we're doing this as a form of market research). I think you'll find it quite interesting. s
Download DAN1197.ZIP at www.pinpub.com/vbd
Daniel Appleman, author of the Visual Basic Programmer's Guide to the Windows API, the Visual Basic Programmer's Guide to the Win32 API, How Computer Programming Works, and Developing ActiveX Components with Visual Basic 5.0: A Guide to the Perplexed, has been developing applications for Microsoft Windows since its release in 1985. In 1991 he founded Desaware Inc., a Campbell, CA-based software company focusing on component-based software and advanced tools for developers. dan@desaware.com, 70303.2252@compuserve.com.