[threadpool] remarques to the documentation
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 ? What do you think about adding a Worker concept, and adding it as parameter to the Strategy template class? 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. Some naming suggestions: * ThreadManagementStrategy sould be a better name for Strategy. * As QueueingPolicy can be either fifo or lifo, SchedulingPolicy sould be more apropiated. * Pending tasks can be more adecuated than queued tasks. You can use take instead of dequeue which is more general. Could you give a use case for lifo order? What about a manual thread management strategy, allowing the user to add new workers or interrupting them? A copy/paste: In the fixed example there is a reference to tp::channel which should be tp::bounded_channel. 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? 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 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? It will be great to have an example justifying the need for the rendezvous channel. A copy/paste: In the smart section smart must replace priority template< typename Attr, typename Ord, typename Enq, typename Deq > struct priority A typo: replace terminateing by terminating in docs and in code Best regrads, Vicente
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
----- Original Message ----- From: <k-oli@gmx.de> To: <boost@lists.boost.org> 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?
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
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. 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
participants (2)
-
k-oli＠gmx.de -
vicente.botet