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

Subject: Re: [boost] [threadpool] remarques to the documentation
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-09-17 14:04:16

----- Original Message ----- 
From: <k-oli_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, September 16, 2008 3:09 PM
Subject: Re: [boost] [threadpool] remarques to the documentation

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

Sorry but in order to know how to cretae other Strategy, Channel, 
QueueingPolicy, Callable currently I need to look on the code for which 
types and functions are currently defined, the documentation do not include 
nothing that can help me.

> > 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?
Non, I'm not refering to the thread_management class. I'm asking for the 
possibility to instantiate another class than the internal worker class in 
the respectives fixed, lazy and adaptive thread management strategies. This 
will allows me to fefine a worker_thread that have its own internal queue of 
sub_tasks.

> > 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 
> ;-)

Do you plan to improve it before the review?

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

So, do you plan to modify the lazy example? From which documentation are you 
talking?

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

So, what is the advantage to reduce the number of threads when there is 
nothing to do? When we will have more things to do we will spent the time in 
creating the threads.

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

Yes, blocking the submiter thread. Maybe we need a mechanism to notify the 
submiter that a given threshold has been reached.

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

Thanks for your comments, what about the  naming suggestions? what about the 
lifo use case?

Regards,

Vicente

_______________________________________________
Unsubscribe & other changes: 
http://lists.boost.org/mailman/listinfo.cgi/boost