vb 多线程

MThreadVB - The Generic Multithreader For VB

Print Email 

Submitted on: 5/29/2002 9:54:04 PM
By: Srideep Prasad  
Level: Advanced
User Rating: By 341 Users
Compatibility:VB 5.0, VB 6.0
Users have accessed this article 87786 times.
  (About the author)        Learn how to multithread easily and effectively with this powerfulaward winning component. With a host of intuitive functions andpowerful ActiveX(tm) events ! To find out more, download now !!!

This article has accompanying files

---

   
Terms of Agreement:   
By using this article, you agree to the following terms...   
1) You may use this article in your own programs (and may compile itinto a program and distribute it in compiled format for languages thatallow it) freely and with no charge.   
2) You MAY NOT redistribute this article (for example to a web site)without written permission from the original author. Failure to do sois a violation of copyright laws.   
3) You may link to this article from another website, but ONLY if it is not wrapped in a frame. 
4) You will abide by any additional copyright restrictions which theauthor may have placed in the article or article's description.

Multithreading in VB - Where the waters become murky....

Multithreading, as far as VB is concerned, is very difficult to implement.Though VB supports multithreading, it basically supports it only for ActiveXEXEs and to some extent in ActiveX Dlls (The ActiveX Dlls basically allow veryprimitive multithreading - It just maps instances of itself onto client threadsthat request its services. If your client is single threaded, the DLL too doesnot multithread !)

Sometime back I had demonstrated a method of multithreading using ActiveXEXEs. Though it is very stable, the trouble is the code tends to be very cumbersome...So I have designed a new generic multithreader, that, though not as stable asmultithreaded ActiveX EXEs, is sufficient for most uses...

A Bit of history....

Soon after I demonstrated how to multithread using ActiveX EXEs, I realizedthat though the technique was useful, and though most of you appreciated it, ittended to be somewhat cumbersome and then I began to think of ways of creatingmultiple threads using other methods.... Soon afterwards, I came across anarticle written by an extremely talented and innovative programmer, MattCurrland (who is unfortunately not a member of PSC), where he demonstrated howto use CreateThread() safely with VB.. But the problem was, the example wasvery complicated and difficult to understand owing to the many class modules itused and the zigzag nature of execution... After hours or effort, punctuatedby crashes, freezes and quite a few reboots, using some inspiration from hisarticle I have created MThreadVB. Though it may not be as "technicallyright" as his code, I had to sacrifice some of the correctness for ease ofuse and the generic architecture.... (Which his code sadly did not provide - Hiswas basically a demo program)

Some Technical Stuff ....

How does the multithreader work ?! You might ask - Here's theanswer !

Normally, all VB programs are heavily dependent on the runtime DLL for its functioning.In VB 6, within the multithreadedfunction (Called By the CreateThread() API once the thread has been created) , any calls
to the runtime DLL fails (due to some reason perhaps which only the Microsoft VB team might know !) causing your program to crash immediately....
Even an API call is not really compiled in "real" native code in VB and is interpreted by the runtime DLL...
An API call too thus ultimately involves calling the runtime DLL,that causes VB to crash.

Those of you who do not believe this can do a simple test - Open the API viewer, select the mciExecute API defied in the Win32API.txt file... Place it in a project and compile it.... Even though this API is a part of WinMM.Dll, you will find no reference to the WinMM.Dll in case you view the executable in the Depencency Viewer (since the code referencing the DLL is not placed "explicitly" in the executable. When you call the API, the actual call to WinMM.Dll is ultimately made by the runtime DLL only) .... But if you were to open the EXE in MS-DOS editor, you can see the text strings "winmm.dll" and "mciExecute" !

Most standard VB statements and functions such as Set = , For...Next etc also call the runtime DLL and ultimately even these fail... (So much for native 'code compilation !)

If an object could be created within the multithreaded procedure, the VB runtime starts behaving properly...
The trouble is,the standard VB instantiator functions fail within the multithreaded procedures...
Therefore, I have used the ThreadAPI.Tlb type library to bypass the Runtime and directly call the OLE/COM 
APIs (This can be verified using the Dependency Viewer) and create a dummy object inside the multithreaded
procedure (using the CoCreateInstance API). After this has been done, the runtime DLL starts 'behaving properly and it is possible to ' call all VB functions safely...

Some features and the Do's and Dont's -

1>The multithreader is completely event based, that is the multithreader notifies the client app of any event such as threads terminating, or the a priority change...

2>For creating all a programmer has to to is the call the CreateWin32Thread() Function, and relax ! So no need to fiddle around any more with ActiveX EXEs !

3>To perform File I/O and to show forms from within threads (which were earlier not supported) do the following -

    Sub MThreadProc(DummyArgument as Variant)   'Your multithreaded procedure
        'Some code....
        pThread.ObjectInThreadContext.SomeSubroutine   
    End Sub

    'In the above code SomeSubroutine is a Sub or can be a function defined in the same form or object in which the Sub MThreadProc is defined (pThread is a reference to the DLL)

    Sub SomeSubRoutine       
        'Your file I/O code or code for creating and displaying forms (Form1.Show etc) goes here 
   End Sub

Special Note: In the above statements, the ObjectInThreadContext property returns a reference to the object containing the multithreaded procedure in context to the new thread 

4>Always call the END statement when you want to end your app

I must thank Robin Lobel for reporting the form show bug(it was never noticed by me) also Willian Tarlton who induced be to think until I got a solution, after he reported his extreme need for file i/o within multithreaded procedures

5>As far as posible do not use the MThreadVB component within the IDE - Use it only with compiled EXEs

Please mail me at [e-mail] if you find bugs or have any suggestions

New ! This article has been updated to include a new class called ThreadLaunchEX that allows multiple thread creation in real time. Though it has not been explained, I must say that it can be used just as the Thread class (used in the Demo) - Only you must identify all threads with a unique threadId parameter. This is not necessary if you are only using the simpler Thread class !

Please vote if you find the code useful... Thank You !

---

A strange "Dissappearance" and a vote of Thanks !
I must first of all thank all my fellow programmers and developers at PSC for their tremendous response to this code... 

However, recently, this piece of code (along with almost 500 others) was deleted due to site hacking. Therefore, I am resubmitting it.. The good news is that Ian, one of the people behind PSC is sincerely pursuing this matter to bring the hacker to justice...!