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

Subject: Re: [boost] [threadpool] new version - interface suggestions
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-02-08 20:18:23

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_at_[hidden]>
To: <boost_at_[hidden]>
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