Threads Queue

[MwnN]

Hi,

I'm trying to setup my app to use threads, a max of 10, but the app could
try to start more then 10 depending on the items selected to process.

If I have 23 items to process I would like to limit my app to use a max of
10 threads at any one time, so the other 10 will go into a thread queue and
only get started once a thread is finished.

I was thinking of using the OnTerminate() event in the thread to trigure the
next thread to start, keeping an array in the main thread with the on/off
setting for the threads, would this be an ok design or is there a prefeered
method for doing such a job.

Thanks,
MwnN

[Chris Uzdavinis (TeamB)]

Post by MwnN
I was thinking of using the OnTerminate() event in the thread to
trigure the next thread to start, keeping an array in the main
thread with the on/off setting for the threads, would this be an ok
design or is there a prefeered method for doing such a job.

A few comments:

1) I'd suggest you not implement your thread strategy that way. You
*can* launch a new thread to handle an item, and let it terminate
when it completes, but you'll end up more overhead just to thread
creation and destruction, plus the context switches from the "main"
thread to each helper thread whenever an item is available to be
processed.

2) There are lots of ways to do this, but threadding is hard. Anyone
that tells you differently probably doesn't know as much about
threadding as they think. You therefore want the simplist solution
you can possibly achieve, with a reasonable performance built into
the design.

3a) Ideas include: pre-launch 10 threads, and have them sitting idle
until something gets enqueued in your work-queue. Notify the
thread pool that there's something to be done, and it will wake one
up which takes the item and processes it. When it completes, it
enqueues itself back into the "available" list of idle threads.

3b) Another solution is the leader-follower pattern. You can read
about it online, but it does avoid the overhead of the context
switches involved in the "one thread launches another and hands
off the work" approach. It can be a little tricky, but still not
too bad.

4) I'd also recommend you think twice before committing your
multi-threaded code to using VCL objects. They're not portable to
other compilers, and are not even true C++ objects. I like the VCL
for what it does, but when I have alternate, portable, standard C++
solutions, I would consider them preferable.

For the things that VCL offers in terms of RAD, you can't beat it
elsewhere. Threadding, however, is really not one of the VCL's
strengths.