This article discusses multithreading issues with Visual Basic.
 

Copyright © 1997-2000 by Daniel Appleman -- All rights reserved.

This article may not be reprinted or distributed electronically or in any other form. Access to this article may be obtained at no cost by accessing our Technical Articles page. Web sites are invited to link directly to the above URL to provide access to this article.

Contents:

• Introduction.

• A quick Review of Multithreading.

• A multithreading Simulator.

• Avoiding Multithreading Problems.

• Visual Basic Service pack #2.

• Why Multithread?

• The Threading Contract.

• The CreateThread API.

• The Create Thread API Revisited.

• Conclusion.

• VB6 update.

• SpyWorks 6.2 update.

• For Further Reference.

You can download the sample code from ftp.desaware.com/SampleCode/Articles/Thread.zip

Just because you can do something, doesn''''t always mean that you should…

With the appearance of the AddressOf operator, an entire industry has developed among authors illustrating how to do previously impossible tasks using Visual Basic. Another industry is rapidly developing among consultants helping users who have gotten into trouble attempting these tasks.

The problem is not in Visual Basic or in the technology. The problem lies in the fact that many authors are applying the same rule to AddressOf techniques that many software companies apply to software in general –- if you can do something, you should. The idea that the newest and latest technology must, by definition, be the best solution to a problem is prevalent in our industry. This idea is wrong. Deployment of technology should be driven primarily by the problem that you are trying to solve, not by the technology that someone is trying to sell you.

Worse yet, just as companies often neglect to mention the limitations and disadvantages of their tools, authors sometimes fail to stress the consequences of some of the techniques that they describe. And magazines and books sometimes neglect their responsibility to make sure that the programming practices that they describe are sound.

As a programmer, it is important to choose the right tool for the job. It is your responsibility to develop code that not only works now under one particular platform, but that works under all target platforms and system configurations. Your code must be well documented and supportable by those programmers who follow you on the project. Your code must follow the rules dictated by the operating system or standards that you are using. Failure to do so can lead to problems in the future as systems and software are upgraded.

Recent articles in the Microsoft Systems Journal and Visual Basic Programmer''''s Journal introduced to Visual Basic programmers the possibility of using the CreateThread API function to directly support multithreading under Visual Basic. In fact, one reader went so far as to contact me and complain that my Visual Basic Programmer''''s Guide to the Win32 API was fatally flawed because I did not cover this function or demonstrate this technique. This article is in part a response to this reader, and in part a response to other articles written on the subject. This article also serves, in part, as an update to chapter 14 of my book "Developing ActiveX Components with Visual Basic 5.0: A Guide to the Perplexed" with regards to new features supported by Visual Basic 5.0 Service Pack 2.

A Quick Review of Multithreading

If you are already well versed in multithreading technology, you may wish to skip this section and continue from the section titled "The Threading Contract" or "New for Service Pack 2."

Everyone who uses Windows knows that it is able to do more than one thing at a time. It can run several programs simultaneously, while at the same time playing a compact disk, sending a fax, and transferring a file. Every programmer knows (or should know) that the computer''''s CPU can only execute one instruction at a time (we''''ll ignore the existence of multiprocessing machines for the time being). How can a single CPU do multiple tasks?

It does this by rapidly switching among the different tasks. The operating system holds all of the programs that are running in memory. It allows the CPU to run each program in turn. Every time it switches between programs, it swaps the internal register values including the instruction pointer and stack pointer. Each of these "tasks" is called a thread of execution.

In a simple multitasking system, each program has a single thread of execution. This means that the CPU starts executing instructions at the beginning of the program, and continues following the instructions in the sequence defined by the program until the program terminates.

Let''''s say the program has five instructions: A B C D and E that execute in sequence (no jumps in this example). When an application has a single thread, the instructions will always execute in exactly the same order: A, B, C, D and E. True, the CPU may take time off to execute other instructions in other programs, but they will not effect this application unless there is a conflict over shared system resources -- another subject entirely.

An advanced multithreading operating system such as Windows allows an application to run more than one thread at a time. Let''''s say that instruction D in our sample application had the ability to create a new thread that started at instruction B and ran through the sequence C and E. The first thread would still be A, B, C, D, E, but when D executed a new thread would begin that would execute B, C, E (we don''''t want to execute D again or we''''ll get another thread).

Exactly what order will the instructions follow in this application?

It could be:

Thread 1

A

B

C

D

E

Thread 2

[1] [2] [3] [4] [5] [6] [7]  下一页