Threading Pool Event()

[Cliff Wells]

On Mon, 2003-07-21 at 00:01, Anand wrote:
> What if you want to make sure that there are exactly
> 'n' threads in the queue a given moment ? 

Why not simply start 'n' threads and have them wait on the queue?

> I had a problem of a similar kind, which I solved by
> deriving a "Thread monitor" class from Queue. I initialized
> the Queue with a given size (the number of threads in it
> a given moment, the number 'n' above). But, I found that
> this does not happen accurately as I wanted. I solved
> it by using a non-blocking queue and managing the exception
> by using an Event and by using my own locks.

You keep saying "threads in the queue".  Why are you putting the threads
in the queue?  Usually the threads run independently and get their
*work* from the queue.  Part of the reason for having a pool of threads
(aside from controlling the number of active threads) is to avoid the
overhead of starting new threads.  By putting threads on the queue and
starting them when there's work to do you lose this benefit.

> The code would look something like this ...
> It uses a polling mechanism with sleeping.

Polling + sleeping seems bad for most applications.  Polling when
there's nothing to do is a waste of CPU, sleeping when there's work to
be done adds latency.  Combining the two is the worst of both worlds
(again qualifying the statement for the general case).

Looking at the code you posted, it isn't clear to me why you would take
this approach.  It appears to me that your fundamental flaw is thinking
that the *threads* must be put on the queue rather than the data the
threads will act on and the problems you faced resulted from that
misunderstanding.

If you disagree, then perhaps you could give an example of an
application that would require this type of approach versus the
traditional producer/pool-of-consumers setup.

Regards,

-- 
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726  (800) 735-0555