From: Moore, Dave (dmoore_at_[hidden])
Date: 2002-03-21 15:03:34
I may be missing something, but...
It seems that your object pools provide lots of flexibility in the ways that
pools of "things" can grow and flexibility in the way that members of the
pool are selected when someone want to "get" a member of the pool.
In the thread pool concept I'm trying to model, idle threads are selected
from the pool so that they can be used to provide an execution context for a
job which is passed to function "add". However, they are "selected" by the
thread platform's scheduling algorithm by virtual of wait()ing on a
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
Like I said, maybe I'm missing something. Can you provide a specific
example in terms of one of your pool_management_alg's where you would do
something different with a pool of threads?
Thanks for the feedback!
> -----Original Message-----
> From: Gennadiy Rozental [mailto:rogeeff_at_[hidden]]
> Sent: Thursday, March 21, 2002 1:53 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] thread_pool.zip added to Files section
> I was using notion of "thread pool" for a long time with my
> previous project. One thing that I found missing in your
> implementation is an ability to be more flexible in terms of
> amount of active threads. Min and max is not enough. I
> attached class object_pool that I was using for this and
> similar purposes. this pool is configured by "manager
> algorithm" that will manage among of object in the pool. I
> have a test module for it either if you will find it interesting.
> --- "Moore, Dave" <dmoore_at_[hidden]> wrote:
> >An implementation of a thread_pool (aka worker pool, worker
> queue) has been
> >uploaded to :
> >Documentation and examples are included.
> >- Implemented purely in terms of Boost.Threads
> >- A thread pool object can execute any function conforming to
> >- Control over the minimum and maximum number of threads
> used in the pool
> >- thread_pool is join()able
> >- cancel is provided, which currently cancels any unexecuted
> jobs, and will
> >eventually cancel any running jobs once
> boost::thread::cancel() exists.
> >Future Directions/Questions:
> >- It may be a good idea to support priorities for jobs, but
> this should be
> >done in concert with the idea of boost::thread::priority
> >- While detach() is included in the sample implementation
> for completeness,
> >it may not be necessary for a thread_pool. If the risks outweigh the
> >utility, it may be removed.
> >Requires Boost 1.27.0. On win32, a deadlock can occur when
> adding new
> >functions to the thread pool for Boost 1.26.0
> >Thanks very much to Bill Kempf for EXTENSIVE feedback and
> comments on the
> >Unsubscribe & other changes:
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk