| | 1042 | |
| | 1043 | -------------------------------------------------------------------------------------------------- |
| | 1044 | == Boost.Sync == |
| | 1045 | * '''Author(s):''' Vicente J. Botet Escribá |
| | 1046 | * '''Version:''' 0.0.0 |
| | 1047 | * '''State:''' work on going |
| | 1048 | * '''Last upload:''' 2010 September 12 |
| | 1049 | * '''Links:''' [http://svn.boost.org/svn/boost/sandbox/synch Boost Sandbox] [http://svn.boost.org/svn/boost/sandbox/synch/libs/synch/doc/index.html Documentation] |
| | 1050 | * '''Categories:''' [#ConcurrentProgramming Concurrent Programming] |
| | 1051 | * '''Description:''' Unifying Boost.Thread and Boost.Interprocess synchronization mechanisms |
| | 1052 | |
| | 1053 | The goal of Boost.Sync is to remove the syntactic differences between the synchronization mechanisms of the Boost.Thread and Boost::Interprocess libraries and be a holder of common mechanism and algorithms working on the common concepts. |
| | 1054 | |
| | 1055 | The differences I have identified up to now are: |
| | 1056 | |
| | 1057 | * The scoped locks can be initialized with static const variables in order to overload the constructor for lock adoption, lock deferral or try to lock. Even if the name of these variables is almost the same, these variables live in different namespace. It would be nice if both libraries use the same type and the same variables. |
| | 1058 | |
| | 1059 | * The shared mutex provide similar service with different names. In addition each implementation provide some functions that are not provided by the other. |
| | 1060 | |
| | 1061 | * The scoped locks live in a different namespace and some have different names with the same semantic. IMO these should be shared. |
| | 1062 | |
| | 1063 | * The exception thrown lives in a different name space and different names with equivalent semantics If we follow the C++0x standard the exception to throw should be system_error. Both libraries could adapt his hierarchy to Boost.System. The drawback is that users of Boost.Thread and Boost.Interprocess will need to link with Boost.System which is not a header only library. |
| | 1064 | |
| | 1065 | * The move semantics (&&) of Boost.Thread should be adapted to the forthcoming Boost.Move library as soon as integrated on the release branch. Boost.Interprocess uses already a detail implementation equivalent to the provided by Boost.Move, so the change will be simpler. |
| | 1066 | |
| | 1067 | * Adapt both libraries interface to use Boost.Chrono, which is yet a non header only library, once it is accepted. |
| | 1068 | |
| | 1069 | Of course, this needs some adaptation of the Thread and Interprocess libraries. |
| | 1070 | |
| | 1071 | Boost.Sync will contain |
| | 1072 | |
| | 1073 | * lockable concepts and locks concepts. |
| | 1074 | * lockables traits, |
| | 1075 | * null_mutex and null_condition classes, |
| | 1076 | * Add some common locks as |
| | 1077 | * strict_lock, nested_strict_lock, |
| | 1078 | * reverse_lock, nested_reverse_lock, |
| | 1079 | * A polymorphic lockable hierarchy. |
