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://listarchives.boost.org/mailman/listinfo.cgi/boost
>