Multithreading in VB6 (solutions that worked for me)
Jimmy B
multithread in VB6. Ok, so it's more of a mini-review, but I like many
others aren't interested in getting our hands too dirty. :)
I tried 2 main packages. Async ($50) from evansprogramming.com and Thread
Factory ($350) from halfx.com. Both have demos of their products you can
try free.
* Async is simply an ActiveX wrapper written in Visual Basic itself. It's
not a bad package at all for $50 and while others may disagree, I feel it
makes multithreading much easier for the beginner or someone who is not
interested in working with ActiveX exe's at all. This OCX/EXE combo seems
to have a limit of starting about 50 threads at a time reliably. Other than
that, it's great and the support is very good and attentive. Of course,
like Schmidt said, you can create your own ActiveX EXE, but this for those
of us who aren't interested in dealing with the technical aspects of
multithreading.
* Thread Factory is a lot more expensive ($350), but it's written in C++ and
is "in-process" rather than "out-of-process" like Active EXE's (Async).
This means that you'll see your actual VB exe (or in IDE) starting threads
in its own process and not by starting up a separate exe. Thread Factory is
therefore much faster and more efficient than Async, but is also somewhat
more complicated to use, so prepare for a learning curve compared to Async.
I've started and received replies from 1000 threads at a time very reliably.
If they provided more examples, especially with their OCX component, it
would have been much easier to get up and running. I'd have to say that the
tech support of Thread Factory was equally as good as Async's.
So if you can get away with 50 threads at a time, want ease of use and a low
price, go with Async (evansprogramming.com), but if you need more power and
start more threads at once, more reliably, I would have to recommend Thread
Factory (halfx.com). I ended up having to use Thread Factory, because I
just couldn't pump out what I needed in Async.
Obviously C++ is the way to go for multithreading, but there are many of us
who are more visionaries than programmers. VB also has the added benefit of
rapid development.
Also, I wanted to thank Schmidt for setting me straight on multithreading in
VB even though I was a pain in the you-know-what.
Klaus H. Probst
=)
--
Klaus H. Probst, MVP
http://www.vbbox.com/
"Jimmy B" <an...@anon.com> wrote in message
news:eWA%23AwwOE...@TK2MSFTNGP10.phx.gbl...
Jimmy B
threads without using ActiveX EXEs?
Vlad Vissoultchev
cheers,
</wqw>
"Jimmy B" <an...@anon.com> wrote in message
news:uJk262$OEHA...@TK2MSFTNGP11.phx.gbl...
Schmidt
"Jimmy B" <an...@anon.com> schrieb im Newsbeitrag
news:eWA%23AwwOE...@TK2MSFTNGP10.phx.gbl...
> * Thread Factory is a lot more expensive ($350), but it's written in C++
and
> is "in-process" rather than "out-of-process" like Active EXE's (Async).
> This means that you'll see your actual VB exe (or in IDE) starting threads
> in its own process and not by starting up a separate exe. Thread Factory
is
> therefore much faster and more efficient than Async, but is also somewhat
> more complicated to use, so prepare for a learning curve compared to
Async.
> I've started and received replies from 1000 threads at a time very
reliably.
> If they provided more examples, especially with their OCX component, it
> would have been much easier to get up and running. I'd have to say that
the
> tech support of Thread Factory was equally as good as Async's.
If you want to use an approach similar to Thread-Factory, then you can go
for free with:
www.datenhaus.de/Downloads/dh_ThreadPool.zip
We have developed this FreeThreaded Helpertools on Top of a Standard-Dll
(DirectCOM.Dll - compiled with Powerbasic7).
Like in ThreadFactory one can load (VB-)COM-WorkerObjects into free Threads
(InProcess).
The main-difference to ThreadFactory is, that with dh_ThreadPool, VB
COM-Objects mustn't be registered - regular VB-Classes can be loaded
directly from the Filesystem into the WorkerThreads and it supports easy to
use interthread-actions, criticalsections, etc..
We allow a maximum of 256 WorkerThreads (again, using more than 30-50
Threads per Process would be bad App-Design unless you're running special
server-Apps on "large irons").
Olaf
Jimmy B
started 1000 threads with Thread Factory and received all of the data back
without a problem. Note these were functions that take little or no CPU
time, but take a long time to respond back, such as network functions. You
can also start up to 1000 threads with the free program called Angry IP
Scanner. If you're making a program such as this, it can scan large
networks 4 times faster than starting 256 threads at a time. Although this
is written in C++, so it's much more efficient than VB or PowerBasic. I
think that's another reason I like Thread Factory. It's efficiency at
dealing with threads is second to none being that it's written in C++ too.
Also, for things like this, since I'm using it for a commercial product, I
like to have someone's neck I can get my hands around. :)
May I ask why PB was used for written the DirectCOM.DLL rather than VB? Is
PB better or easier than VB for this?
Schmidt
> [Network-Scanners running 1000 Threads]...
> If you're making a program such as this, it can scan large
> networks 4 times faster than starting 256 threads at a time.
Never have used such a Tool, but I think, the performance-gain is at least
nonlinear.
If a program has to switch between 1000 Threads - than it generates much
more overhead compared with switching 256 Threads or below.
Don't know about your timeouts for e.g. ICMPEchoRequests, but assuming they
are 256 msec, then the UI-Thread would have to manage 1000 ThreadMessages
per second in a 256-Threads-WorstCase-Scenario and (theoretically) 4000
Msgs/second, if 1000 Threads were used.
Can the ThreadCallback-Mechanism (often used: PostMessage) handle such
msg-volumes without problems?
On my PIII-500 the Maximum-PostMessage-Rate is ca. 2000 Msgs/second
(singlethreaded, no additional overhead for threadswitching of 1000
Threads).
Additionally the most Socket/Network-Functions support async mechanisms
(Completion-Functions, -Ports), where the OS handles the requests for you,
so that you can reduce the ThreadCount of your app to a reasonable value
(don't know, if there anything exists in the WinsockAPI for ICMP-Functions
too).
> May I ask why PB was used for written the DirectCOM.DLL rather than VB?
Is
> PB better or easier than VB for this?
With PB it is easier, to create Standard-Dlls (DirectCOM.Dll is a
Standard.Dll).
Much of already existing VB-Code can be reused inside PB per Copy&Paste.
PB has an easy to use Threading-Model and has built in COM-Support since
Version 7, so there was not much effort, to implement a FreeThreader for use
with (VB-)COM-Objects.
Olaf
Jimmy B
> Never have used such a Tool, but I think, the performance-gain is at least
> nonlinear.
> If a program has to switch between 1000 Threads - than it generates much
> more overhead compared with switching 256 Threads or below.
> Don't know about your timeouts for e.g. ICMPEchoRequests, but assuming
> they
> are 256 msec, then the UI-Thread would have to manage 1000 ThreadMessages
> per second in a 256-Threads-WorstCase-Scenario and (theoretically) 4000
> Msgs/second, if 1000 Threads were used.
> Can the ThreadCallback-Mechanism (often used: PostMessage) handle such
> msg-volumes without problems?
I don't know, but I've ran Angry IP Scanner on a 500 mhz. Celeron with 1000
threads and 250ms pinging about 5000 addresses. It took no more than a
couple percent of the CPU time and took less time than when I throttle it
down to 256 threads. I don't know how he does it, but I'm pretty impressed.
And he does more than just ping, he's also sending UDP packets to port 137
to get the MAC Address, etc.
Now, when I create threads very quickly in VB with any method (5 ms between
starts) and I'm receiving from those threads at the same time, it often
times uses 100% CPU with a 1000 ms. ICMP timeout until the program stops
starting threads, then the CPU time goes way down when just receiving. And
this is on an Athlon 1900+ (1.67ghz). When running it on slower machines
the program just runs slower, sending out IPs slower, but everything does
come back. And because I'm killing threads after they return, there are no
more than about 100 threads running at a time. Again, it's the starting of
threads that is slow, not the receiving of info.
Vlad Vissoultchev
spent in the worker threads. that's why VB is not used for ISAPI filter for
instance :-))
you can try to code a threadfunc that's calling imported APIs (through a
typelib) and do the job *w/o* init'ing the run-time but this will be a feat
by itself :-)) if you have to send an ICMP and and UDP packet then this
probably could be done.
cheers,
</wqw>
Jens Neuhalfen
[snip]
> more than about 100 threads running at a time. Again, it's the starting of
> threads that is slow, not the receiving of info.
Jens
Jimmy B
about 100 threads running at once no matter how many pings are made, but it
does depend on the timeout of the ping. If a user types in 30 seconds for a
ping timeout (albeit rare, but is possible), then my software could very
well have started 1000 threads before it gets back any pings to recycle the
threads. Again, very rare, so I'm pretty safe.