[boost] [threadpool]thread management strategies

Subject: [boost] [threadpool]thread management strategies
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-09-16 01:37:47

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