[boost] Threads: pool_policies for boost::thread_pool

From: Moore, Dave (dmoore_at_[hidden])
Date: 2002-03-22 16:32:58

I've attached a file pool_policy.hpp which sketches out a design for a
pool_policy class, and describes how boost::thread_pool might use that
class.  I also provided two sample policies:

"min_max_timed_policy", which is a reimplementation of the original,
hardcoded policy in thread_pool.

"limit_backlog_policy", which is a policy which adds threads only if the
backlog of work reaches a certain threshold.  This was the only "corner"
case that I personally could come up with that wasn't covered by the basic
min_max_timed policy.  It could come in handy when the cost of executing a
work unit is some fraction of the cost of launching a new thread...

The way that thread_pool holds its reference to a policy is probably not
ideal, consider that part for exposition only.

Thanks very much to Gennadiy for his comments and general
pool_management_alg.  I think your stuff is quite general and flexible.  I
chose to rename your functions because it helped me think about pool
management specifically in this domain (threads).  I would imagine that we
would return to your more general terms in the final implementation, since
these ideas apply to pools of objects other than threads.

Dave

> -----Original Message-----
> From: Gennadiy Rozental [mailto:rogeeff_at_[hidden]]
> Sent: Thursday, March 21, 2002 7:27 PM
> To: boost_at_[hidden]
> Subject: RE: [boost] thread_pool.zip added to Files section
> 
> 
> 
> 
> --- "Moore, Dave" <dmoore_at_[hidden]> wrote:
> >As for the size, given a min and max size, the size of the 
> pool will shrink
> >towards the min when threads are idle for longer than the 
> timeout value, and
> >will grow towards the max whenever a new job arrives and no 
> idle threads are
> >available.
> 
> 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.
> 
> Gennadiy.
> 
> 
> _____________________________________________________________
> A free email account your friends will never forget!
> Get YOURNAME_at_[hidden]  at http://www.emailaccount.com/
> 
> _____________________________________________________________
> Run a small business? Then you need professional email like 
> you_at_[hidden] from Everyone.net  http://www.everyone.net?tag
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>