|
Boost-Commit : |
Subject: [Boost-commit] svn:boost r84627 - in branches/release: boost/thread libs/thread libs/thread/doc
From: vicente.botet_at_[hidden]
Date: 2013-06-04 02:01:55
Author: viboes
Date: 2013-06-04 02:01:54 EDT (Tue, 04 Jun 2013)
New Revision: 84627
URL: http://svn.boost.org/trac/boost/changeset/84627
Log:
Thread: merge 84331 to fix #8576.
Properties modified:
branches/release/boost/thread/ (props changed)
branches/release/libs/thread/ (props changed)
Text files modified:
branches/release/boost/thread/externally_locked_stream.hpp | 2 +-
branches/release/boost/thread/lock_traits.hpp | 7 +++++--
branches/release/boost/thread/lockable_traits.hpp | 7 ++++++-
branches/release/boost/thread/strict_lock.hpp | 4 ++--
branches/release/libs/thread/doc/external_locking.qbk | 4 ++--
branches/release/libs/thread/doc/mutex_concepts.qbk | 30 +++++++++++++++---------------
branches/release/libs/thread/doc/sync_streams.qbk | 2 +-
7 files changed, 32 insertions(+), 24 deletions(-)
Modified: branches/release/boost/thread/externally_locked_stream.hpp
==============================================================================
--- branches/release/boost/thread/externally_locked_stream.hpp (original)
+++ branches/release/boost/thread/externally_locked_stream.hpp 2013-06-04 02:01:54 EDT (Tue, 04 Jun 2013)
@@ -80,7 +80,7 @@
};
template <typename Stream, typename RecursiveMutex>
- struct is_strict_lock_sur_parolle<stream_guard<Stream, RecursiveMutex> > : true_type
+ struct is_strict_lock_sur_parole<stream_guard<Stream, RecursiveMutex> > : true_type
{
};
Modified: branches/release/boost/thread/lock_traits.hpp
==============================================================================
--- branches/release/boost/thread/lock_traits.hpp (original)
+++ branches/release/boost/thread/lock_traits.hpp 2013-06-04 02:01:54 EDT (Tue, 04 Jun 2013)
@@ -26,7 +26,7 @@
* An strict lock is a lock ensuring the mutex is locked on the scope of the lock
* There is no single way to define a strict lock as the strict_lock and
* nesteed_strict_lock shows. So we need a metafunction that states if a
- * lock is a strict lock "sur parolle".
+ * lock is a strict lock "sur parole".
*/
template <typename Lock>
@@ -34,7 +34,10 @@
template <typename Lock>
-struct is_strict_lock : is_strict_lock_sur_parolle<Lock> {};
+struct is_strict_lock_sur_parole : is_strict_lock_sur_parolle<Lock> {};
+
+template <typename Lock>
+struct is_strict_lock : is_strict_lock_sur_parole<Lock> {};
}
#include <boost/config/abi_suffix.hpp>
Modified: branches/release/boost/thread/lockable_traits.hpp
==============================================================================
--- branches/release/boost/thread/lockable_traits.hpp (original)
+++ branches/release/boost/thread/lockable_traits.hpp 2013-06-04 02:01:54 EDT (Tue, 04 Jun 2013)
@@ -173,11 +173,16 @@
#endif
template<typename T>
- struct is_recursive_mutex_sur_parolle
+ struct is_recursive_mutex_sur_parole
{
BOOST_STATIC_CONSTANT(bool, value = false);
};
template<typename T>
+ struct is_recursive_mutex_sur_parolle : is_recursive_mutex_sur_parole<T>
+ {
+ };
+
+ template<typename T>
struct is_recursive_basic_lockable
{
BOOST_STATIC_CONSTANT(bool, value = is_basic_lockable<T>::value &&
Modified: branches/release/boost/thread/strict_lock.hpp
==============================================================================
--- branches/release/boost/thread/strict_lock.hpp (original)
+++ branches/release/boost/thread/strict_lock.hpp 2013-06-04 02:01:54 EDT (Tue, 04 Jun 2013)
@@ -108,7 +108,7 @@
};
//]
template <typename Lockable>
- struct is_strict_lock_sur_parolle<strict_lock<Lockable> > : true_type
+ struct is_strict_lock_sur_parole<strict_lock<Lockable> > : true_type
{
};
@@ -213,7 +213,7 @@
//]
template <typename Lock>
- struct is_strict_lock_sur_parolle<nested_strict_lock<Lock> > : true_type
+ struct is_strict_lock_sur_parole<nested_strict_lock<Lock> > : true_type
{
};
Modified: branches/release/libs/thread/doc/external_locking.qbk
==============================================================================
--- branches/release/libs/thread/doc/external_locking.qbk (original)
+++ branches/release/libs/thread/doc/external_locking.qbk 2013-06-04 02:01:54 EDT (Tue, 04 Jun 2013)
@@ -478,7 +478,7 @@
In order to make this code compilable we need to store either a Lockable or a `unique_lock<Lockable>` reference depending on the constructor. Store which kind of reference we have stored,and in the destructor call either to the Lockable `unlock` or restore the ownership.
-This seams too complicated to me. Another possibility is to define a nested strict lock class. The drawback is that instead of having only one strict lock we have two and we need either to duplicate every function taking a `strict\_lock` or make these function templates functions. The problem with template functions is that we don't profit anymore of the C++ type system. We must add some static metafunction that check that the Locker parameter is a strict lock. The problem is that we can not really check this or can we?. The `is_strict_lock` metafunction must be specialized by the strict lock developer. We need to belive it "sur parolle". The advantage is that now we can manage with more than two strict locks without changing our code. Ths is really nice.
+This seams too complicated to me. Another possibility is to define a nested strict lock class. The drawback is that instead of having only one strict lock we have two and we need either to duplicate every function taking a `strict\_lock` or make these function templates functions. The problem with template functions is that we don't profit anymore of the C++ type system. We must add some static metafunction that check that the Locker parameter is a strict lock. The problem is that we can not really check this or can we?. The `is_strict_lock` metafunction must be specialized by the strict lock developer. We need to belive it "sur parole". The advantage is that now we can manage with more than two strict locks without changing our code. Ths is really nice.
Now we need to state that both classes are `strict_lock`s.
@@ -548,7 +548,7 @@
T& get(Locker& lock) {
BOOST_CONCEPT_ASSERT((StrictLockerConcept<Locker>));
- BOOST_STATIC_ASSERT((is_strict_lock<Locker>::value)); // locker is a strict locker "sur parolle"
+ BOOST_STATIC_ASSERT((is_strict_lock<Locker>::value)); // locker is a strict locker "sur parole"
BOOST_STATIC_ASSERT((is_same<Lockable,
typename lockable_type<Locker>::type>::value)); // that locks the same type
#ifndef BOOST_THREAD_EXTERNALLY_LOCKED_DONT_CHECK_OWNERSHIP // define BOOST_THREAD_EXTERNALLY_LOCKED_NO_CHECK_OWNERSHIP if you don't want to check locker ownership
Modified: branches/release/libs/thread/doc/mutex_concepts.qbk
==============================================================================
--- branches/release/libs/thread/doc/mutex_concepts.qbk (original)
+++ branches/release/libs/thread/doc/mutex_concepts.qbk 2013-06-04 02:01:54 EDT (Tue, 04 Jun 2013)
@@ -176,7 +176,7 @@
The user could require that the mutex passed to an algorithm is a recursive one. Whether a lockable is recursive or not can not be checked using template meta-programming. This is the motivation for the following trait.
-[section:is_recursive_mutex_sur_parolle `is_recursive_mutex_sur_parolle` trait -- EXTENSION]
+[section:is_recursive_mutex_sur_parole `is_recursive_mutex_sur_parole` trait -- EXTENSION]
// #include <boost/thread/lockable_traits.hpp>
@@ -185,15 +185,15 @@
namespace sync
{
template<typename L>
- class is_recursive_mutex_sur_parolle: false_type; // EXTENSION
+ class is_recursive_mutex_sur_parole: false_type; // EXTENSION
template<>
- class is_recursive_mutex_sur_parolle<recursive_mutex>: true_type; // EXTENSION
+ class is_recursive_mutex_sur_parole<recursive_mutex>: true_type; // EXTENSION
template<>
- class is_recursive_mutex_sur_parolle<timed_recursive_mutex>: true_type; // EXTENSION
+ class is_recursive_mutex_sur_parole<timed_recursive_mutex>: true_type; // EXTENSION
}
}
-The trait `is_recursive_mutex_sur_parolle` is `false_type` by default and is specialized for the provide `recursive_mutex` and `timed_recursive_mutex`.
+The trait `is_recursive_mutex_sur_parole` is `false_type` by default and is specialized for the provide `recursive_mutex` and `timed_recursive_mutex`.
It should be specialized by the user providing other model of recursive lockable.
@@ -211,7 +211,7 @@
}
}
-This traits is true_type if is_basic_lockable and is_recursive_mutex_sur_parolle.
+This traits is true_type if is_basic_lockable and is_recursive_mutex_sur_parole.
[endsect]
[section:is_recursive_lockable `is_recursive_lockable` trait -- EXTENSION]
@@ -226,7 +226,7 @@
}
}
-This traits is true_type if is_lockable and is_recursive_mutex_sur_parolle.
+This traits is true_type if is_lockable and is_recursive_mutex_sur_parole.
[endsect]
@@ -1156,13 +1156,13 @@
[endsect] [/ mutex_type]
-[section:is_strict_lock_sur_parolle `is_strict_lock_sur_parolle<L>`]
+[section:is_strict_lock_sur_parole `is_strict_lock_sur_parole<L>`]
-As the semantic "ensures that the associated mutex is locked during the lifetime if the lock. " can not be described by syntactic requirements a `is_strict_lock_sur_parolle` trait must be specialized by the user defining the lock so that the following assertion is true:
+As the semantic "ensures that the associated mutex is locked during the lifetime if the lock. " can not be described by syntactic requirements a `is_strict_lock_sur_parole` trait must be specialized by the user defining the lock so that the following assertion is true:
- is_strict_lock_sur_parolle<L>::value == true
+ is_strict_lock_sur_parole<L>::value == true
-[endsect] [/ is_strict_lock_sur_parolle]
+[endsect] [/ is_strict_lock_sur_parole]
[section:owns_lock `cl.owns_lock(m);`]
@@ -1183,8 +1183,8 @@
The following classes are models of `StrictLock`:
* strict_lock: ensured by construction,
-* nested_strict_lock: "sur parolle" as the user could use adopt_lock_t on unique_lock constructor overload without having locked the mutex,
-* __lock_guard__: "sur parolle" as the user could use adopt_lock_t constructor overload without having locked the mutex.
+* nested_strict_lock: "sur parole" as the user could use adopt_lock_t on unique_lock constructor overload without having locked the mutex,
+* __lock_guard__: "sur parole" as the user could use adopt_lock_t constructor overload without having locked the mutex.
[endsect] [/ Models]
@@ -2026,9 +2026,9 @@
template <typename Lock>
class nested_strict_lock;
template <typename Lockable>
- struct is_strict_lock_sur_parolle<strict_lock<Lockable> >;
+ struct is_strict_lock_sur_parole<strict_lock<Lockable> >;
template <typename Lock>
- struct is_strict_lock_sur_parolle<nested_strict_lock<Lock> >;
+ struct is_strict_lock_sur_parole<nested_strict_lock<Lock> >;
#if ! defined BOOST_THREAD_NO_MAKE_STRICT_LOCK
template <typename Lockable>
Modified: branches/release/libs/thread/doc/sync_streams.qbk
==============================================================================
--- branches/release/libs/thread/doc/sync_streams.qbk (original)
+++ branches/release/libs/thread/doc/sync_streams.qbk 2013-06-04 02:01:54 EDT (Tue, 04 Jun 2013)
@@ -26,7 +26,7 @@
template <class Stream, typename RecursiveMutex=recursive_mutex>
class stream_guard;
template <typename Stream, typename RecursiveMutex>
- struct is_strict_lock_sur_parolle<stream_guard<Stream, RecursiveMutex> > : true_type {};
+ struct is_strict_lock_sur_parole<stream_guard<Stream, RecursiveMutex> > : true_type {};
// Stream-like operators
template <typename Stream, typename RecursiveMutex, typename T>
Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk