Re: [boost] [threadpool] remarques to the documentation

Subject: Re: [boost] [threadpool] remarques to the documentation
From: k-oli_at_[hidden]
Date: 2008-09-16 09:09:30

Hello Vicente,
nice that you also correct the docu.

Am Dienstag, 16. September 2008 08:06:52 schrieb vicente.botet:
> Hi,
>
> 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 
lazy<AdjustmentPolicy>
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::pool<
>   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 
configuration.

> 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?

right

> 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
> channel.

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.

regards,
Oliver