Re: [boost] [threadpool] new version - interface suggestions

9 Feb 2009

      Hi,

I have implemented some of the suggestions I made to you some weeks ago. But I have no changed the tests. The interested people can get the modifications included in Boost Vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=interthreads.zip&directory=Concurrent%20Programming& (directory boost/tp.)

I'm working now on the functions on the namespace this_task.

Oliver, please let me know which modifications do you accept.

Best,
Vicente

Task class
* Adding a get_future function allows to use wait_for_all and wait_for_any or overload these functions for tasks.
DONE
* A task is an asynchronous completion token so it will be great if it shares the same interface as futures:
    * Add wait, wait_until, wait_for
DONE

and as threads 
    * Add detach (this allows to free the interrupter)
DONE
    * Add interruption_requested
DONE
    * Add join (equivalent to wait)
DONE
    * Add joinable (equivalent interrupter pressent)
DONE

* It could be useful to get the  pool  associated to a task (this is possible if task is a inner class of pool, see below). This allows a user having a reference to a task to shutdown a thread pool
    * Add a function get_thread_pool()
DONE

Pool class

* It will be interesting to be able to wait actively on other synchronization mechanisms. 
    * Add a public re_schedule_until_ready
    template <typename ACT>
    void re_schedule_until_ready(ACT& fut ) { 
        if ( tss_worker_.get() ) {
            while ( ! fut.is_ready() )
                if ( ! tss_worker_->re_schedule() ) break;
        }
    }
DONE

Implementation
* I see that the  struct impl_future declare its functions virtual? If the task class has a Pool parameteryou will know the pool type and so no need to use a virtual functions.
DONE
The single inconvenient is that the user needs to declare its task as

    task<pool_type, int> tsk = p.submit(f);

But if you we register the task class with Boost.Typeof the user can write

    BOOST_AUTO(tsk, p.submit(f))

or in C++0x

    auto tsk = p.submit(f);

You just need to add a file
    // boost/tp/typeof/task.hpp
    #ifndef BOOST_TP_TYPEOF_TASK__HPP

    #include <boost/tp/task.hpp>
    #include <boost/typeof/typeof.hpp>
    #include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP()
    BOOST_TYPEOF_REGISTER_TEMPLATE(boost::tp::task, 1)
    #endif

----- Original Message ----- 
From: <k-oli@gmx.de>
To: <boost@lists.boost.org>
Sent: Friday, January 16, 2009 2:37 PM
Subject: Re: [boost] [threadpool] new version - interface suggestions

Hello,
...
Task class
* Adding a get_future function allows to use wait_for_all and wait_for_any
or overload these functions for tasks.
I would prefer to keep future as an implementation detail
...
* A task is an asynchronous 
completion token so it will be great if it shares the same interface as
futures: * Add wait, wait_until, wait_for
* Add a callback setting
and as threads
* Add detach (this allows to free the interrupter)
* Add interruption_requested
* Add join (equivalent to wait)
* Add joinable (equivalent interrupter pressent)
that's possible - I could rename the functions
...
* It could be useful to get the pool associated to a task (this is
possible if task is a inner class of pool, see below). This allows a user
having a reference to a task to shutdown a thread pool * Add a function
get_thread_pool()
I was also thinking about such constructs
...
* Task can also be seen as asynchronous executors which are able to fork a
new task associated to the execution of a function * Add a fork function
which will submit a new function to the pool associated to the task
task<R>::fork(f);
it doubles the functionalisty of pool::submit and I want to keep the interface 
small
a task should be associated only with one function passes/submitted to the 
pool
...
* Add a this_task::fork function which submit a new function to the
pool associated to the current worker. This avoid to pass the task or pool
as parameters to other functions called in this thread.
I'll think about this
...
Pool class
* It will be interesting to be able to wait actively on other
synchronization mechanisms. * Add a public re_schedule_until_ready
template <typename ACT>
void re_schedule_until_ready(ACT& fut ) {
if ( tss_worker_.get() ) {
while ( ! fut.is_ready() )
if ( ! tss_worker_->re_schedule() ) break;
}
}
For example this_task::sleep_until and sleep_for:
struct time_reached {
time_reached(system_time& abs_time) : abs_time(abs_time) {}
bool is_ready() {
return get_system_time() >= abs_time_;
}
};
this_task::sleep_until(system_type& abs_time) {
if (this_task::get_thread_pool()) {
time_reached t(abs_time);
this_task::get_thread_pool()->re_schedule_until_ready(t);
} else this_thread::sleep_until(abs_time);
}
looks interresting
...
Implementation
* I see that the struct impl_future declare its functions virtual? If you
declare the task class local to the pool class you will know the pool type
and so no need to use a wrapper, i.e. What do you think?
The single inconvenient is that the user needs to declare its task as
pool_type::task<int> tsk = p.submit(f);
But if you we register the task class with Boost.Typeof the user can write
BOOST_AUTO(tsk, p.submit(f))
or in C++0x
auto tsk = p.submit(f);
You just need to add a file
// boost/tp/typeof/task.hpp
#ifndef BOOST_TP_TYPEOF_TASK__HPP
#include <boost/tp/task.hpp>
#include <boost/typeof/typeof.hpp>
#include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP()
BOOST_TYPEOF_REGISTER_TEMPLATE(boost::tp::task, 1)
#endif
OK - I'll incorporate this
...
Documentation
* It is not clear from the documentation which is the role of timed_submit.
I supose it is returns if the task can not be put on the channel queue.
Could you clarify?
Yes - you are right I should make it more clear in the documentation
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] [threadpool] new version - interface suggestions

vicente.botet