RE: [boost] thread_pool.zip added to Files section

From: Moore, Dave (dmoore_at_[hidden])
Date: 2002-03-21 23:15:43

> 
> That is the point. You inprint in your implementation 
> following algorithm of idle threads management:
> 1. Minimum number of threads m1.
> 2. Maximum number of threads m2.
> 3. If thread is older t1 -> destroy.
> 4. If need more thread - create one.
> 
> Are you sure  that this model wil fit for any possible usage 
> of thread pool. What if I do not want to destroy my threads 
> ever during program lifetime of vice vesa immidiatelly when 
> returned to pool? What if I just want support some ballance 
> between amount of used threads at the moment and amoumt of 
> idle ones? What if I want ballance parameters to change 
> depend of time of the day or load of the server? And so on.
> 
> I would prefer provide a solution that allows more flexibility

I appreciate the desire for flexibilty.  However, I do think that the
combination of min, max, and timeout covers alot of the common cases,
though.  Having idle threads standing by to handle an influx of new jobs can
be very important, but a longer timeout and/or a higher minimum thread count
can help in this case, too.  

If we were to use the pool_managemnet algorithms....

First, a library would have to provide at least a "fixed size" algorithm and
a min/max/timeout algorithm.  Users of the library should -not- be forced to
create their own algorithm just to use the thread pool....

I think the model you presented would have to -also- take into account:

1.  A thread that is deciding whether to exit should take into account
whether other jobs are queued up.

2.  A thread asking whether it should exit must express whether it has just
-immediately- finished a job, or whether it has been idle for the timeout
period.

3.  The algorithms -might- have to take timeouts into account.  This is the
most troubling problem, since the pooled threads tend to use the timeouts
during a wait() operation which 

Basically, many dynamic algorithms would require these "facts" as inputs to
get_object and put_object, so these arguments would have to be also added to
enlarge_storage and hold_returned...

This seems like alot of complication, but it might be manageable with
default algorithms and a small pool_management_alg interface so that users
aren't scared from implementing their own pool mgmt. algorithms.  If the
interface is too daunting, no one will customize the algorithm, and this
will defeat the purpose of making thread_pool flexible.

I would like to hear from Bill Kempf on this issue - how much flexibility is
needed hear?

Regards, 
Dave

> Gennadiy.

> _______________________________________________
> Unsubscribe & other changes: 
http://lists.boost.org/mailman/listinfo.cgi/boost