February 2009 - Boost - lists.preview.boost.org

[thread|interprocess] Boost.Synchro: Towards a generic view of synchronization mechanisms
by vicente.botet 09 Feb '09

09 Feb '09

Hi, Currently there are two libraries defining mutex, condition variables and locks in Boost (Boost.Thread and Boost.Interprocess), which have similar interfaces but with some differences. This has as consequence that we can not interchange them. One of the reasons is that we are not working with concepts, and algorithms. Both boost::mutex and boost::interprocess_mutex are models of the same Lockable concept, but not because they share a common syntax but because they share a common semantics. Can we see a binary_semaphore as a Lockable? Well, usually a binary_semaphore will define operations such a post and wait, so binary_semaphore do no share the common syntax as boost::mutex and boost::interprocess_mutex. On the semantic side wait can be assimilated to lock and post to unlock. By the way, there are also other syntactical differences between the Boost.Thread and Boost.Interprocess classes. So how can we write gerenic code that can be used with every model of the concepts. The idea consist in switching from the OO paradigm to the functional paradigm. We found the same approach Boost.MPL and Boost.Fusion between others. So instead of requiring that a model of the concept Lockable defines the member functions lock and unlock, we require that the functional expressions lock(m) and unlock(m) are well founded. A generic Synchro library can define a default implementation that forwards to the member function. namespace synchro { template <typename Lockable> void lock(Lockable& lockable) { return lockable.lock(); } } Now we can overload the lock function on a binary_semaphore as namespace synchro { void lock(binary_semaphore& sem) { return sem.wait(); } } Just another example for a class template anotherLockableModel that models the Lockable concept but that with acquire/release functions. We need to overload again the lock function. namespace synchro { template< typename T> void lock( anotherLockableModel<T>& lockable ) { return lockable.acquire(); } } However, there are cases where overloads do not suffice (as described in N1295 - Partial specialization of function templates), and we need to use partial specialization of function templates. On compiler that do not support partial specialization of function templates we can use a workaround, that is, use partial specialization of class templates. The default implementation will now forward to a static function of a class which has forward to the member function namespace synchro { namespace partial_specialization_workaround { template< typename Lockable > struct lock { static void apply( Lockable& lockable ) { return lockable.lock(); } }; } template <typename Lockable> void lock(Lockable& lockable) { return partial_specialization_workaround::lock<Lockable>::apply(lockable); } } So now the user can partially specialize the class template partial_specialization_workaround::lock and define the apply function as needed: namespace synchro { namespace partial_specialization_workaround { template< typename T> struct lock <anotherLockableModel<T> >{ static void apply( anotherLockableModel<T>& lockable ) { return lockable.acquire(); } }; } } Once we have all the Lockable operations defined in this way, and do the same for ConditionVariable, we can define in a generic way unique_lock, shared_lock and upgrade_lock that works with boost::shared_mutex as boost::interprocess::interprocess_upgradable_mutex. This could leverage these libraries to define its own locks classes. Ion, Anthony, Boosters what do you think of applying this approach to get a generic Synchro library? Should the partial_specialization_workaround be applied systematicaly or it complicates things? Thanks, Vicente

2 3

[factory] Including documentation
by Rutger ter Borg 09 Feb '09

09 Feb '09

Dear all, After about 30 minutes searching and digging I found out that apparently a Boost.Factory library is accepted into Boost, and committed to trunk under Boost.Functional. Would it be an idea to include its documentation under the main documentation as well -- or is this already done in 1.38.0? Thanks, Kind regards, Rutger ter Borg

1 0

[1.38.0] Release candidate
by Beman Dawes 09 Feb '09

09 Feb '09

The release candidates are up at http://boost.cowic.de/rc/ Daniel, I'd appreciate it if you could check the docs to make sure there were no glitches. I'll hold off releasing the files on SourceForge until I've heard back from you. Thanks, --Beman

3 5

[constrained-value] Some observations and questions.
by Jeroen N. Witmond [Bahco] 09 Feb '09

09 Feb '09

Greetings, Please forgive me for intruding on the Boost Development mailing list. I'm rather new to Boost, but I'm in love with it, because IMHO it shows C++ as it should be used. :) While browsing this mailing list, I came across the review announcement[1] for the Boost Constrained Value library[2]. I like the concept, so I downloaded[3] and installed the library. I also installed file boost/utility/swap.hpp from the sandbox. I had to hack the example program[4] to get around "[boost] [utility/swap] Ambiguous overload"[5]. To get familiar with Boost and the Boost Constrained Value library, I first rewrote the example program into a Boost.Test testcase[6]. (I have tried not to disturb the documentation generated from this file, but I did not test this.) As testcase, it runs succesfully, with the hack mentioned above. (At least for me, Emacs has problems with font-lock-mode[7] on this file. The original example program does not demonstrate this problem.) In the section on Custom error policies in the example program, perhaps it should be explicitely stated that: - on entry into the error handler, constraint(new_value) will always be false. An error handler that neither changes the constraint, nor supplies a valid value can therefore throw unconditionally. - on entry into the error handler, constraint(value) will only be false during the construction of an object with an invalid value. If the error handler does not throw in this case, the library will raise signal SIGABRT (application abort requested). - the only case where the error handler can be empty is when the constraint always returns true, as in 'template <typename ValueType> class unconstrained'[8]. This code[9] illustrates these points. Next I was itching to create and more real-life use case for the Boost Constrained Value library, with special attention on improving error reporting. So I wrote four template classes[10], implementing non-positive, non-negative, positive and negative constraints over any integral type. (This code still can be improved in many ways.) These constrained integers can be declared like: positiveInteger<int> i; // Construction with value 0 would fail, BOOST_CHECK_EQUAL( i, 1 ); // so it is set to 1. They can used like teir base type. In case of constraint violations (e.g. 'i = 1;' for 'i' above), an exception is thrown, which derives from both std::logic_error and boost::exception. The std::logic_error::what() returns: Failed assert(1 <= 0); And from the boost::exception, the following information can be retrieved (slightly edited to fit the newsgroup): constrained-integer.hpp:168: In '[very long function name]': Failed assert(-1 > 0); constrained-integer.cpp:82: Constraint was defined here. See the first testcase in the Boost.Test testsuite[11] for the code that produced these messages from boost::exception. The remainder of the testsuite runs the four template classes both against fundamental types, and against classes that implement infinite precision integer arithmetic. This showed that I needed to implement 'bool operator == (const Integer & v) const' for these classes, but not for the fundamental types. As implementing this operator==() for fundamental types results in compiler errors, the implementation is present only when preprocessor symbol 'CLASS_TYPE' is defined. (My attempt to hack this in the Boost Constrained Value library source failed.) Note that no hackery is needed for the relational operators used in the constraints. Otherwise, the testsuite compiles correctly and runs almost as expected. It would appear that in the process I may have discovered a bug[12] in the mp_math library in the sandbox. One question I have is related to the requirement of the Constrained Value library that the constraint and error handler objects must be completely constructed before the constrained object is constructed. In these four template classes, I handle this by deriving my template type (e.g. nonPositiveInteger) from the constraint class and indirectly from the error handler class. The purpose is to allow these template types to be used as drop-in replacements for the types they constrain. In this context it appears to work, but I'm having second thoughts about its validity and advisability. Although it is not a Boost question, is there anybody who wants to comment? One thing that has gotten me completely stumped is deriving my own template class from constrained_value::unconstrained. Whatever I try, I get the weirdest of compiler error messages. See the bottom of [10] and [11] for my latest attempt in the section guarded by '#ifdef DO_UNCONSTRAINED'. I must be missing something obvious. Also all other comments will be appreciated. Regards, Jeroen. PS: All files referenced in this email and authored by me are released under the Boost Software License, Version 1.0[99]. Note however that this code is not of release quality. [ 1] http://lists.boost.org/Archives/boost/2008/12/145581.php [ 2] http://student.agh.edu.pl/~kawulak/constrained_value/index.html [ 3] http://rk.go.pl/f/constrained_value.zip [ 4] file libs/constrained_value/doc/src/examples.cpp in [3]. [ 5] http://lists.boost.org/Archives/boost/2007/10/128494.php [ 6] http://www.xs4all.nl/~jnw/boost/constrained-value/test-constrained-value.cpp [ 7] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510475 [ 8] file boost/constrained_value/unconstrained.hpp in [3]. [ 9] http://www.xs4all.nl/~jnw/boost/constrained-value/understanding-ignore.cpp [10] http://www.xs4all.nl/~jnw/boost/constrained-value/constrained-integer.hpp [11] http://www.xs4all.nl/~jnw/boost/constrained-value/constrained-integer.cpp [12] http://lists.boost.org/boost-users/2009/01/43824.php [99] http://www.boost.org/LICENSE_1_0.txt

2 1

[constrained] constrained_vector
by Neal Becker 09 Feb '09

09 Feb '09

I'm interested in something like constrained, but applied to a vector of values. The case I'm interested in is a homogeneous vector of bounded int values, with bounds set at runtime. It is trivial to have a vector<bounded<int> >, but this would not be space efficient in the case where the policies, bounds on all the values are the same. I'm thinking that maybe some parts of constrained (such as policies) could be reused, independent of the rest of constrained. Has anyone looked into the idea of constrained vector?

3 4

[1.38.0] beta 2 release candidate
by Beman Dawes 09 Feb '09

09 Feb '09

The beta 1 release candidate from earlier in the week had enough issues that I decided not to push it out to sourceforge. Most (all?) of those issues have been corrected, and a new release candidate is up at http://boost.cowic.de/rc/ If no showstoppers surface I plan to move this beta to sourceforge tomorrow (Friday) and announce it here, the users list, and the announce list. The final 1.38.0 release would then come about week later. There are pending bug fixes for Boost.Python and Boost.Asio that are not in the beta but Dave and Chris are planning to have ready for the final release. --Beman

10 28

[constrained_value] Review version
by Robert Kawulak 09 Feb '09

09 Feb '09

Hi all, I've made some minor changes to the Boost Constrained Value library: - reorganized the structure of header files, - renamed saturating/saturating_int into clipping/clipping_int, - using boost::swap where applicable (if you don't have it, you need to get it from http://svn.boost.org/svn/boost/branches/release/boost/utility/swap.hpp) - made no_constraint policy public, - now the stream operators are not defined if BOOST_NO_IOSFWD macro is defined, - fixed identifiers containing "__" (not allowed by C++), - fixed minor language errors in the docs. The library is ready for the formal review, which starts this monday (1.12). It is only missing the detailed regression tests, which will be added after the review. Currently the examples file (libs\constrained_value\doc\src\examples.cpp) can be used instead -- it uses most of the functionality of the library and should compile and run returning 0. As usually, the code and documentation can be downloaded here: http://rk.go.pl/f/constrained_value.zip The documentation is also available online here: http://rk.go.pl/r/constrained_value Any comments and problem reports for platforms that has not been tested yet are very welcome. Best regards, Robert Kawulak -=##############=- "I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones." - Albert Einstein

3 4

[constrained_value] serialization
by Neal Becker 09 Feb '09

09 Feb '09

constrained_value does not currently support serialization. 1. Should it be added to the lib? 2. What would be a suggested implementation?

3 5

[threadpool] new version - supporting future library (C++0x) from Anthony Williams
by k-oli＠gmx.de 09 Feb '09

09 Feb '09

Hello, I've uploaded a new version of boost.threadpool (v17) at http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-…. 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'. best regards, Oliver

3 10

[interthreads] Library under development v0.4
by vicente.botet 09 Feb '09

09 Feb '09

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=intert… 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á

1 0