Am Sonntag, 23. November 2008 15:09:13 schrieb vicente.botet:

----- Original Message ----- From: <k-oli@gmx.de> To: <boost@lists.boost.org> Sent: Saturday, November 22, 2008 8:40 PM Subject: [boost] [threadpool] new version - supporting future library(C++0x) from Anthony Williams

...

Hello,

I've uploaded a new version of boost.threadpool (v17) at http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boos t-threadpool.v17.tar.gz&directory=Concurrent%20Programming&.

It uses the future implementation of Anthony Williams (C++0x - available at http://www.justsoftwaresolutions.co.uk/files/n2561 future.hpp). Please save it as file 'future'.

Hi,

is there any reason you use the 'just' implementation instead of the boost one?

? Don't know what you want to say ?

Not every body use Visual C++. At the end we are in Boost, isn't it?

I don't use Visual C++ - I'm developing on UNIX. Still don't know what you want to say. Oliver

Am Sonntag, 23. November 2008 16:26:05 schrieb vicente.botet:

Sorry for the noise, I belive that you were using the 'Just Solution Software' implementation.

Yes - I'm using future library from Anthony Williams (scheduled for boost peer review). Because the interface seams to become part of C++0x I modifed boost.threadpool in order to use it. I hope Anthony will provide its implementation to boost. The question is (as you already asked) what happens with Braddocks future library - is a peer review still required? Should Anthonies future lib added to boost by default? regards, Oliver

----- 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

I understand your concern, but what about overloading wait_for_all and wait_for_any for tasks, this will preserve the implementation detail but give to the user a generic way to wait for the completion of N tasks? This will allow also to submit a task once a set of tasks have been finished, something similar to your old chained_submit, isn't it? As the specialization will be partial we will need to define wait_for_all and wait_for_any using an auxiliary class until all the compilers support partial specialization of functions. I'll suggest this to Anthony. Best, Vicente

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