In Visual Basic it is possible to obtain one or more additional separate code threads to operate a single program. The threads are stable and secure and communication between them is provided for intrinsicly. There is no need to hack the language with unpredictable API''''s.

This page focuses on how that is done and demonstrates the problem you may have (or not be aware of) in starting these threads running.

Client and server are object oriented programming (OOP) terms. To simplify matters in the ensuing discussion, the client will be a standard EXE. The server will be an ActiveX component object instantiated by the client. The client sends information and requests to the server object. The server responds when the job is done by raising an event in the client and usually returning some processed information to the client.

A thread is a list of assembly level instructions that the CPU (central processing unit) of your computer executes one after another, one at a time, all the way until a program ends and releases the thread. The Windows?programs that you can switch between when you click on the taskbar at the bottom of the screen are operating on separate threads. The amazing thing is that not only can you switch from one program to another, but they can all run at once!

This is possible because the CPU can switch code threads. It stops executing one thread, saves all the information about that thread, loads all the information about the next thread in line, and then starts executing that set of instructions. Countless thread code switches are happening right now in your computer every second as you read this.

So technically the programs on your taskbar are not all running at once, but the switching normally happens so fast that it seems like they are.

A switch occurs whenever the CPU gets a break from the program holding the presently executing thread. In Visual Basic these breaks are provided automatically when waiting for some type of input (a key press or a mouse click). If your code performs many instructions without a break, it may monopolize the CPU so that other programs can''''t get their share of CPU time. In such a case, it is up to you as a good programmer to be courteous and judiciously allow breaks with the DoEvents statement.

If you play music on your computer while you type an email reply, or if you keep more than one web browser window open at the same time to download one page while you read another, then you are aware of the benefits of separate code threads.

In these instances, the operating system provides separate threads automatically, and the applications really don''''t have to work together as client and server.

When could we take advantage of separate code threads in a single program? ?/FONT> To synchronize input of data with processing data. An example would be allowing an user to complete a second form, while the first is being processing. ?/FONT> To synchronize complex computations where separate, alternating processing may allow for more rapid completion. i.e. - The result of processing on one thread arrives in time to be used on the other. ?/FONT> To resolve or eliminate reentrancy quirks and conflicts that arise in a single thread when it overlaps itself and generally performs operations in an order not anticipated. Chasing these overlaps with flags and exits ends up becoming just plain bad programming. ?/FONT> To provide a model of a remote server during development. In network or internet settings, it is possible to instantiate a remote server object for a local client program. Here again a separate thread is provided automatically because, of course, two machines can not run in the same thread. However, the code for such a remote instantiation is usually subtly if not significantly different than the code for a local server. A separately threaded local program will provide a precise model to enable the programmer to think "remotely."

Of course such a discussion would be moot if there were no vehicle for implementation. Fortunately, Visual Basic has provided us such a tool through ActiveX, and specifically the ActiveX EXE type component. It is there specifically to give us a separate thread - if you only need a same thread library, then choose an ActiveX DLL as your project.

ActiveX has been designed by Microsoft to nudge Visual Basic programmers toward object oriented programming. It is through the instantiation of a required public class that ActiveX is able to pipe us into the safe haven of the COM standard and provide us with secure conversations between separate threads. You will also be happy to learn that the App Object has a .ThreadID property which will be your compass for exploration.

It is the ActiveX EXE we shall explore for the separate code thread it provides. Visual Basic has the ability to allow for multi-threads of separately threaded EXE servers (additional threads for each instantiation) through unattended execution compilation options. The examples herein only deal with single, separate threads of execution.

Being a single, separate thread does not mean that it can not have more than one client instantiating and calling it. When a component has one thread of execution, code for only one object executes at a time. The Automation feature of the Component Object Model (COM) deals with this situation by serializing requests. That is, the requests are queued and processed one at a time until all have been completed. It is limited because if control is yielded, the next queued call is allowed entry and if unanticipated, reentrancy problems may occur.

Simply calling a public method of a server running on a separate thread will start the server executing code. The problem is that the calling client will wait at that instruction for the return from the server. This will happen even if the call is to a Sub in the server (i.e. expecting no return value as with a function).

To illustrate:

''''==============================================
''''The Server Code: compiled as an ActiveX EXE
''''     Class name: threadServer
''''==============================================
Option Explicit
Event done(id&)

Public Sub waitAwhile()
    Dim j#, k#
    For j = 1 To 300000
        k = j
        DoEvents
    Next
    
    RaiseEvent done(App.ThreadID)
End Sub

''''==============================================
''''The Client Code run from the VB IDE
''''==============================================
Option Explicit
Private WithEvents ts1 As threadServer

Private Sub Form_Load()
    AutoRedraw = True
    Set ts1 = New threadServer
End Sub

Private Sub Form_Click()
    Cls
    ts1.waitAwhile
    Print "Client done at: " & Str$(Timer) & _
        "   on thread: " &
[1] [2]  下一页