[threadpool]thread management strategies

Hi, I have do a comparaison of the three thread management strategies fixed, lazy and adaptive header files and I found some incoherences that are possible bugs. * In fixed.hpp and lazy.hpp the size_ function should be const std::size_t size_() { return worker_.size(); } * In lazy.hpp submit_ is not used channel_iterator submit_( channel_item const& itm) { return channel_.put( itm); } * In adaptive and lazy add the assertion on constructor BOOST_ASSERT( lwm <= hwm); * In adaptive void core_size( std::size_t size) { shared_lock< shared_mutex > lk( mtx_worker_); core_size_ = size; } must use a unique_lock instead of a shared_lock * In lazy std::size_t max_size() { return max_size_; } should't have a shared_lock guard. The three files have more in common than differences. Doesn't the following pools behaves identically boost::tp::pool< boost::tp::fixed, boost::tp::unbounded_channel< boost::tp::fifo >
pool( boost::tp::max_poolsize( 10) );
boost::tp::pool< boost::tp::lazy< depend_on_core >, boost::tp::unbounded_channel< boost::tp::fifo >
pool( boost::tp::preallocate( 10), boost::tp::core_poolsize( 10), boost::tp::max_poolsize( 10) );
boost::tp::pool< boost::tp::adaptive< depend_on_core, keep_core_size
, boost::tp::unbounded_channel< boost::tp::fifo > pool( boost::tp::preallocate( 10), boost::tp::core_poolsize( 10), boost::tp::max_poolsize( 10), boost::posix_time::very_high );
Looking at the differences we have the following feature model PoolSize: fixed|variable[AdjustmentPolicy, ShrinkPolicy] ShrinkPolicy: no_shrink | shrink [RecreatePolicy] I was wondering if we can define a class thread_management taking a feature expression and use it as follows thread_management<fixed> to mean the current fixed thread_management<variable<AdjustmentPolicy> > to mean the current lazy<AdjustmentPolicy> thread_management<variable<AdjustmentPolicy, shrink<RecreatePolicy> > > The advantage of this approach is that we avoid the incoherences. The liability is that this class must use metaprogramming in its implementation to preserv the efficiency. What do you think? Vicente

Hello Vicente, thank you for looking through the code. Am Dienstag, 16. September 2008 07:37:47 schrieb vicente.botet:
* In adaptive and lazy add the assertion on constructor BOOST_ASSERT( lwm <= hwm);
I've romved the assertion because it is a runtime error (user defines vaules) and bounded_channel already checks high- and low watermark.
* In lazy std::size_t max_size() { return max_size_; } should't have a shared_lock guard.
Because max_size_ is a invariante I beleive it is safe to leave it unprotected (mutex).
Doesn't the following pools behaves identically
boost::tp::pool< boost::tp::fixed, boost::tp::unbounded_channel< boost::tp::fifo >
pool( boost::tp::max_poolsize( 10) );
boost::tp::pool< boost::tp::lazy< depend_on_core >, boost::tp::unbounded_channel< boost::tp::fifo >
pool( boost::tp::preallocate( 10),
boost::tp::core_poolsize( 10), boost::tp::max_poolsize( 10) );
boost::tp::pool< boost::tp::adaptive< depend_on_core, keep_core_size
,
boost::tp::unbounded_channel< boost::tp::fifo >
pool(
boost::tp::preallocate( 10), boost::tp::core_poolsize( 10), boost::tp::max_poolsize( 10), boost::posix_time::very_high );
yes
thread_management<fixed> to mean the current fixed thread_management<variable<AdjustmentPolicy> > to mean the current lazy<AdjustmentPolicy> thread_management<variable<AdjustmentPolicy, shrink<RecreatePolicy> > > What do you think?
Looks interesting - I've to think up how to realize it in C++. regards, Oliver

Hi Olivier, ----- Original Message ----- From: <k-oli@gmx.de> To: <boost@lists.boost.org> Sent: Tuesday, September 16, 2008 2:45 PM Subject: Re: [boost] [threadpool]thread management strategies
Hello Vicente, thank you for looking through the code.
Am Dienstag, 16. September 2008 07:37:47 schrieb vicente.botet:
* In adaptive and lazy add the assertion on constructor BOOST_ASSERT( lwm <= hwm);
I've romved the assertion because it is a runtime error (user defines vaules) and bounded_channel already checks high- and low watermark.
Does it means that you can remove it on fixed.hpp (230)?
* In lazy std::size_t max_size() { return max_size_; } should't have a shared_lock guard.
Because max_size_ is a invariante I beleive it is safe to leave it unprotected (mutex).
In the case of adaptive the guard is used, so ... As you don't comment the other points, do you mean that you will takes these points in account?
thread_management<fixed> to mean the current fixed thread_management<variable<AdjustmentPolicy> > to mean the current lazy<AdjustmentPolicy> thread_management<variable<AdjustmentPolicy, shrink<RecreatePolicy> > > What do you think?
Looks interesting - I've to think up how to realize it in C++.
Let me know if I can help. Best, Vicente
participants (2)
-
k-oli@gmx.de
-
vicente.botet