Topic: Interest in is_lockable type trait
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 23 Mar 2013 18:16:45 +0100
Raw View
This is a multi-part message in MIME format.
--------------050107020906030008060705
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
Boost.Thread defines an algorithm to lock all the locks on a range.
Non-member function lock(begin,end)
template<typename ForwardIterator>
void lock(ForwardIterator begin,ForwardIterator end);
Requires: The value_type of ForwardIterator must implement the Lockable
concept
Effects: Locks all the Lockable objects in the supplied range in an
unspecified and indeterminate order in a way that avoids deadlock. It is
safe to call this function concurrently from multiple threads with the
same mutexes (or other lockable objects) in different orders without
risk of deadlock. If any of the lock() or try_lock() operations on the
Lockable objects in the supplied range throws an exception any locks
acquired by the function will be released before the function exits.
This prototype conflicts with the following one
template <class L1, class L2, class... L3> void lock(L1&, L2&, L3&...);
so we need some kind of SFINAE to disambiguate the two overloads.
Currently Boost.Thread provides a is_lockable type trait that is This
trait is true_type if the parameter meets the Lockable requirements.
Is there an interest for this trait in the standard?
Best,
Vicente
P.S. I know that Boost.Thread could define the lock on a Range so that
there is no more ambiguity. This was just a motivating example.
template<typename Range>
void lock(Range& range);
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--------------050107020906030008060705
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<p> Boost.Thread defines an algorithm to lock all the locks on a
range.<br>
</p>
<p>Non-member function lock(begin,end) <br>
<br>
template<typename ForwardIterator><br>
void lock(ForwardIterator begin,ForwardIterator end);</p>
<p>Requires: The value_type of ForwardIterator must implement the
Lockable concept <br>
Effects: Locks all the Lockable objects in the supplied range in
an unspecified and indeterminate order in a way that avoids
deadlock. It is safe to call this function concurrently from
multiple threads with the same mutexes (or other lockable objects)
in different orders without risk of deadlock. If any of the lock()
or try_lock() operations on the Lockable objects in the supplied
range throws an exception any locks acquired by the function will
be released before the function exits. <br>
</p>
<p>This prototype conflicts with the following one<br>
</p>
<p> template <class L1, class L2, class... L3> void
lock(L1&, L2&, L3&...);<br>
</p>
<p>so we need some kind of SFINAE to disambiguate the two overloads.
<br>
</p>
<p>Currently Boost.Thread provides a is_lockable type trait that is
This trait is true_type if the parameter meets the Lockable
requirements.
<br>
</p>
<br>
Is there an interest for this trait in the standard? <br>
<br>
Best,<br>
Vicente<br>
<br>
P.S. I know that Boost.Thread could define the lock on a Range so
that there is no more ambiguity. This was just a motivating example.<br>
<br>
template<typename Range><br>
void lock(Range& range);
<p><br>
</p>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------050107020906030008060705--
.