Subject: [boost] [interthreads] Library under development v0.4
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-02-08 20:01:05
Hi,
I have just released the version 0.4, which includes since my last publicly announced version 0.3.0:
Version 0.4.0, Fevrary 8, 2009 Improvements + bug fixes
New Features:
* New free functions for all the AsynchronousCompletionToken operations, providing a higher degree of freedom.
* Missing have_all_values(), have_all_exception() and are_all_ready() functions on AsynchronousCompletionToken fusion tuples.
* get_all: getting all the values from a tuple of AsynchronousCompletionToken works now.
* fork_after overloaded for a single dependency
* wait_all overloaded for a single ACT.
* wait_for_all evaluate one of its elements on the current thread
* No need to use wait_and_get() on thread_specific_shared_ptr<> to synchronize with the decoration if the thread is created using a AsynchronousExecutor decorator. In this case the synchro is done before returning the AsynchronousCompletionToken. See the tutorial and the mono_thread_id example.
Fixed Bugs:
v0.2#1: ae::get_all do not work yet. get_all() do not work because fusion transform sequence function can not take non const sequences. I have emulated it using set_all() and a transformation for a tuple of _ACT to a tuple of result_type.
v0.3.1#1: keep alive mechanism crash when setting set_on_dead_thread() before enabling the mechanism. This was due to the fact that there were no default data for the backup.
v0.3.1#2: keep alive mechanism do not detect dead threads. We need to reset the counters only when the period is 0.
v0.3.1#3: The set_on_dead_thread() setting is not recovered by embeeding kep_alive enablers/disablers. The problem is that the on_dead() the function and the thread pointer were stored on the backup. It is enough to store them on the thread_keep_alive_ctx and make the functions thread_safe.
Version 0.3.1, January 25, 2009 bug fixes
Fixed Bugs:
v0.3#3: scheduler::do_test_fork_after_wait do not work yet. To solve this issue it enough to define boost::move for tp::task
v0.3#2: scheduler::do_test_fork_after_get do not work yet. To solve this issue it enough to define boost::move for tp::task
v0.3#1: scheduler::do_test_wait_for_any do not work yet. Not reproductible
v0.2#2: Some trouble with the use of tp::pool directly, use scheduler instead. Four issues.
The parameter to fork on tp:pool was a const F& instead of a F.
Direct use of fork_all resolved for the other AsynchronousExecutor by ADL, which could not be the case for the tp::pool.
fork specialization for tp::pool incorrect.
use of the default handle instead of asynchronous_completion_token traits class
For those who don't know the library yet here are some of its features:
* An asynchronous execution framework working with AsynchronousExecutor and AsynchronousCompletionToken. It includes some generic functions working on AsynchronousExecutor and AsynchronousCompletionToken concepts:
* fork and fork_all to execute functions asynchronously.
* fork_after: request an AsynchronousExecutor to execute a function asynchronously once each one of AsynchronousCompletionToken in the dependency tuple parameter are ready. It is similar to the async_with_dependencies proposed Peter Dimov.
* generic wait_for_all, wait_for_any to execute asynchronously functions and wait for the completion of all or any of them.
* generic get, join, ... free functions to synchroyze on an AsynchronousCompletionToken
* generic get_all, join_all, ... free functions to synchroyze on multiple AsynchronousCompletionTokens
* Some AsynchronousExecutors and AsynchronousCompletionTokens models
* basic_threader: can be seen as a thread factory executing asynchronously a function on the returned thread.
* launchers: Lanchers can be seen as a future factory executing asynchronously a function on a hiden thread.
* threader/joiner: A Threader runs a unary function in its own thread. A Threader can be seen as a Joiner factory executing asynchronously a function on a thread encapsulated on the returned Joiner. The joiner is used to synchronise with and pick up the result from a function or to manage the encapsulated thread.
* tp::pool and tp::task customization as an AsynchronousExecutor and an AsynchronousCompletionToken respectively. tp::pool can be seen as a tp::task factory executing asynchronously a function on a pool of threads.
a generic asynchronous_executor_decorator which allows to decorate the function to be evaluated asynchronously.
* Some thread extension
* A thread_decoration class allowing to define setup/cleanup functions which will be called only once by thread (if the thread function is decorated with thread_decorator): setup before the thread function and cleanup at thread exit. It is used together with asynchronous_executor_decorator
* A thread_decorator/thread_decorate class/function which decorate a thread function in order to call the setup and the cleanup of all the thread_decorations.
* A thread specific shared pointer which is an extension of the thread_specific_ptr providing access to this thread specific context from other threads. As it is shared the stored pointer is a shared_ptr instead of a raw one.
* A thread keep alive mechanism: this mechanism allows to detect threads that do not prove that they are alive by calling to the keep_alive_point regularly. When a thread is declared dead a user provided function is called, which by default will abort the program.
The library is available at
Boost Sandbox: https://svn.boost.org/svn/boost/sandbox/interthreads and
Boost Vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=interthreads.zip&directory=Concurrent%20Programming&
Includes every thing on the Sandbox + Html documentation + Boost.Futures + Boost.ThreadPool adaptations
I'd appreciate it if people could take a look, test it on their compiler and give me some feedback.
Best regrads,
Vicente Juan Botet Escribá