Subject: Re: [boost] [threadpool] remarques to the documentation
Date: 2008-09-16 09:09:30
nice that you also correct the docu.
Am Dienstag, 16. September 2008 08:06:52 schrieb vicente.botet:
> I'm reading the documentation and I don't find any description of the
> concepts Strategy, Channel, QueueingPolicy, Callable.
> Do you plan to describe explicitly these concepts in the documentation ?
I thought that the docu is descriptive enought - isn't it?
> What do you think about adding a Worker concept, and adding it as parameter
> to the Strategy template class?
Which Worker concept? Do you refer to your previous post?
thread_management<fixed> to mean the current fixed
thread_management<variable<AdjustmentPolicy> > to mean the current
thread_management<variable<AdjustmentPolicy, shrink<RecreatePolicy> > >
> I think that the tutorial must be reworked, including more practical
> examples, and starting from the most basic use and going on each one of the
> use cases where the different features are better adapted, currently it
> seams more to a informal reference manual.
As many other developers - I'm a little bit lazy writing documentation ;-)
> What about a manual thread management strategy, allowing the user to add
> new workers or interrupting them?
> In the lazy example
> // creates a lazy pool with unbounded channel
> // tasks are processed in FIFO order
> // the pool contains ten worker threads
> // no worker threads are started at construction
> boost::tp::lazy< depend_on_core >,
> boost::tp::unbounded_channel< boost::tp::fifo >
> > pool(
> boost::tp::core_poolsize( 5)
> boost::tp::max_poolsize( 10) );
> Can this pool have more than 5 worker threads? If the worker threads are
> created "if current poolsize size is less than core_poolsize or the
> channel is full", as the channel is unbounded_channel the channel will
> never be full, so when the current poolsize size will be 5 no new threads
> will be created, ins't it?
Yes - that's true. The docu of the java implementation notes also this special
> the adaptive ThreadManagementStrategy seems to be in contradiction to the
> goal of the threadpool "Using a thread pool over creating a new thread for
> each task may result in better performance and better system stability
> because the overhead for thread creation and destruction is negated." Could
> you present a use case in which this adaptive strategy could be useful?
In some cases the work-load may vary over the time, for instance short period
with hight load and long prediods with no work items.
> In channnel section you say "If the channel becomes empty all worker
> threads are set to sleep until a new task is enqueued." Except for the
> adaptive strategy which has a keep_alive timeout, the other waits until a
> new task is submited, isn't it?
> Which are the advantages/liabilities of a bounded channel respect to an
> unbounded one? When it is better to use one of them?
with unbounded channel you can reach memory boundaries.
bounded channel restricts the tasks the pool accepts.
> It will be great to have an example justifying the need for the rendezvous
I don't believe it is relevant for real world code. It could be used for
testing - I've included rendezvous channel because the java implementation
also contained such a channel. Maybe I'll remove it if it confuses people.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk