Topic: Interest in a tuple<unique_lock<>> factory?
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 20 Nov 2012 19:07:48 +0100
Raw View
Hi,
I want a shorter syntax for the following pattern
{
std::unique_lock<boost::mutex> l1(m1, defer_lock);
std::unique_lock<boost::mutex> l2(m2, defer_lock);
std::unique_lock<boost::mutex> l3(m3, defer_lock);
std::lock(l1, l2, l3);
// do something with protect with m1,m2,m3
}
I have found a solution using a factory that returns a tuple of locks
auto lks = make_unique_locks(m1, m2, m3);
where make_unique_locks is defined as
template <typename ...Lockable>
std::tuple<std::unique_lock<Lockable>...> make_unique_locks(
Lockable& ...mtx);
{
std::lock(mtx...);
return
std::tuple<std::unique_lock<Lockable>...>(std::unique_lock<Lockable>(mtx, std::adopt_lock)...);
}
It is worth adding this minor function to the standard?
Best,
Vicente
--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 20 Nov 2012 11:13:06 -0800 (PST)
Raw View
------=_Part_492_25898557.1353438786989
Content-Type: text/plain; charset=ISO-8859-1
What if you want to use something besides "std::adopt_lock"? If we're
making a special function for this stuff, it should have the same
expressive power as the original.
Also, there is a difficulty with multi-lock operations. They all have to be
done in the same order or else you can get synchronization problems. If
we're making a special function for this, then it should help solve that
problem by ordering the mutexes in some way. Perhaps by using their
addresses (since mutex's can't be moved or copied) to order them.
On Tuesday, November 20, 2012 10:07:51 AM UTC-8, viboes wrote:
>
> Hi,
>
> I want a shorter syntax for the following pattern
>
> {
> std::unique_lock<boost::mutex> l1(m1, defer_lock);
> std::unique_lock<boost::mutex> l2(m2, defer_lock);
> std::unique_lock<boost::mutex> l3(m3, defer_lock);
> std::lock(l1, l2, l3);
>
> // do something with protect with m1,m2,m3
> }
>
> I have found a solution using a factory that returns a tuple of locks
>
> auto lks = make_unique_locks(m1, m2, m3);
>
> where make_unique_locks is defined as
>
> template <typename ...Lockable>
> std::tuple<std::unique_lock<Lockable>...> make_unique_locks(
> Lockable& ...mtx);
> {
> std::lock(mtx...);
> return
> std::tuple<std::unique_lock<Lockable>...>(std::unique_lock<Lockable>(mtx,
> std::adopt_lock)...);
>
> }
>
> It is worth adding this minor function to the standard?
>
> Best,
> Vicente
>
>
>
--
------=_Part_492_25898557.1353438786989
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
What if you want to use something besides "std::adopt_lock"? If we're makin=
g a special function for this stuff, it should have the same expressive pow=
er as the original.<br><br>Also, there is a difficulty with multi-lock oper=
ations. They all have to be done in the same order or else you can get sync=
hronization problems. If we're making a special function for this, then it =
should help solve that problem by ordering the mutexes in some way. Perhaps=
by using their addresses (since mutex's can't be moved or copied) to order=
them.<br><br>On Tuesday, November 20, 2012 10:07:51 AM UTC-8, viboes wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">Hi,
<br>
<br>I want a shorter syntax for the following pattern
<br>
<br> {
<br> std::unique_lock<boost::<wbr>mutex> l1(m1, de=
fer_lock);
<br> std::unique_lock<boost::<wbr>mutex> l2(m2, de=
fer_lock);
<br> std::unique_lock<boost::<wbr>mutex> l3(m3, de=
fer_lock);
<br> std::lock(l1, l2, l3);
<br>
<br> // do something with protect with m1,m2,m3
<br> }
<br>
<br>I have found a solution using a factory that returns a tuple of locks
<br>
<br> auto lks =3D make_unique_locks(m1, m2, m3);
<br>
<br>where make_unique_locks is defined as
<br>
<br> template <typename ...Lockable>
<br> std::tuple<std::unique_lock<<wbr>Lockable>...>=
make_unique_locks(=20
<br>Lockable& ...mtx);
<br> {
<br> std::lock(mtx...);
<br> return=20
<br>std::tuple<std::unique_lock<<wbr>Lockable>...>(std::unique_=
<wbr>lock<Lockable>(mtx, std::adopt_lock)...);=20
<br>
<br> }
<br>
<br>It is worth adding this minor function to the standard?
<br>
<br>Best,
<br>Vicente
<br>
<br>
<br></blockquote>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_492_25898557.1353438786989--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Tue, 20 Nov 2012 14:30:09 -0500
Raw View
On Nov 20, 2012, at 2:13 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Also, there is a difficulty with multi-lock operations. They all have to =
be done in the same order or else you can get synchronization problems. If =
we're making a special function for this, then it should help solve that pr=
oblem by ordering the mutexes in some way. Perhaps by using their addresses=
(since mutex's can't be moved or copied) to order them.
std::lock(m1, m2, m3)'s job is to lock m1, m2 and m3 without deadlock -- in=
whatever order they are supplied. The ordering problem is already solved =
in the standard.
Howard
--=20
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 20 Nov 2012 11:53:49 -0800 (PST)
Raw View
------=_Part_505_18977944.1353441229447
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, November 20, 2012 11:30:12 AM UTC-8, Howard Hinnant wrote:
>
> On Nov 20, 2012, at 2:13 PM, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
>
> > Also, there is a difficulty with multi-lock operations. They all have to
> be done in the same order or else you can get synchronization problems. If
> we're making a special function for this, then it should help solve that
> problem by ordering the mutexes in some way. Perhaps by using their
> addresses (since mutex's can't be moved or copied) to order them.
>
> std::lock(m1, m2, m3)'s job is to lock m1, m2 and m3 without deadlock --
> in whatever order they are supplied. The ordering problem is already
> solved in the standard.
>
> Howard
>
>
Yes. My point being that a std::tuple of std::unique_lock does *not* solve
that problem. And that's what his multi-lock operation returns.
--
------=_Part_505_18977944.1353441229447
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Tuesday, November 20, 2012 11:30:12 AM UTC-8, Howard Hinnant wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On Nov 20, 2012, at 2:13 PM=
, Nicol Bolas <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"2mkW563GZDsJ">jmck...@gmail.com</a>> wrote:
<br>
<br>> Also, there is a difficulty with multi-lock operations. They all h=
ave to be done in the same order or else you can get synchronization proble=
ms. If we're making a special function for this, then it should help solve =
that problem by ordering the mutexes in some way. Perhaps by using their ad=
dresses (since mutex's can't be moved or copied) to order them.
<br>
<br>std::lock(m1, m2, m3)'s job is to lock m1, m2 and m3 without deadlock -=
- in whatever order they are supplied. The ordering problem is alread=
y solved in the standard.
<br>
<br>Howard
<br>
<br></blockquote><div><br>Yes. My point being that a std::tuple of std::uni=
que_lock does <i>not</i> solve that problem. And that's what his multi-lock=
operation returns.<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_505_18977944.1353441229447--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 20 Nov 2012 20:56:21 +0100
Raw View
This is a multi-part message in MIME format.
--------------070600030204050707090808
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 20/11/12 20:53, Nicol Bolas a =E9crit :
>
>
> On Tuesday, November 20, 2012 11:30:12 AM UTC-8, Howard Hinnant wrote:
>
> On Nov 20, 2012, at 2:13 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
> > Also, there is a difficulty with multi-lock operations. They all
> have to be done in the same order or else you can get
> synchronization problems. If we're making a special function for
> this, then it should help solve that problem by ordering the
> mutexes in some way. Perhaps by using their addresses (since
> mutex's can't be moved or copied) to order them.
>
> std::lock(m1, m2, m3)'s job is to lock m1, m2 and m3 without
> deadlock -- in whatever order they are supplied. The ordering
> problem is already solved in the standard.
>
> Howard
>
>
> Yes. My point being that a std::tuple of std::unique_lock does /not/=20
> solve that problem. And that's what his multi-lock operation returns.
>
Why do you think it doesn't works?
Vicente
--=20
--------------070600030204050707090808
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 20/11/12 20:53, Nicol Bolas a
écrit :<br>
</div>
<blockquote
cite="mid:f1cbc409-295b-4fc2-848f-9209dc197aac@isocpp.org"
type="cite"><br>
<br>
On Tuesday, November 20, 2012 11:30:12 AM UTC-8, Howard Hinnant
wrote:
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Nov 20,
2012, at 2:13 PM, Nicol Bolas <<a moz-do-not-send="true"
href="javascript:" target="_blank"
gdf-obfuscated-mailto="2mkW563GZDsJ">jmck...@gmail.com</a>>
wrote:
<br>
<br>
> Also, there is a difficulty with multi-lock operations.
They all have to be done in the same order or else you can get
synchronization problems. If we're making a special function for
this, then it should help solve that problem by ordering the
mutexes in some way. Perhaps by using their addresses (since
mutex's can't be moved or copied) to order them.
<br>
<br>
std::lock(m1, m2, m3)'s job is to lock m1, m2 and m3 without
deadlock -- in whatever order they are supplied. The ordering
problem is already solved in the standard.
<br>
<br>
Howard
<br>
<br>
</blockquote>
<div><br>
Yes. My point being that a std::tuple of std::unique_lock does <i>not</i>
solve that problem. And that's what his multi-lock operation
returns.<br>
</div>
<br>
</blockquote>
Why do you think it doesn't works?<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------070600030204050707090808--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 20 Nov 2012 12:52:46 -0800 (PST)
Raw View
------=_Part_734_13162230.1353444766095
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tuesday, November 20, 2012 11:56:22 AM UTC-8, viboes wrote:
>
> Le 20/11/12 20:53, Nicol Bolas a =E9crit :
> =20
>
>
> On Tuesday, November 20, 2012 11:30:12 AM UTC-8, Howard Hinnant wrote:=20
>>
>> On Nov 20, 2012, at 2:13 PM, Nicol Bolas <jmck...@gmail.com> wrote:=20
>>
>> > Also, there is a difficulty with multi-lock operations. They all have=
=20
>> to be done in the same order or else you can get synchronization problem=
s.=20
>> If we're making a special function for this, then it should help solve t=
hat=20
>> problem by ordering the mutexes in some way. Perhaps by using their=20
>> addresses (since mutex's can't be moved or copied) to order them.=20
>>
>> std::lock(m1, m2, m3)'s job is to lock m1, m2 and m3 without deadlock --=
=20
>> in whatever order they are supplied. The ordering problem is already=20
>> solved in the standard.=20
>>
>> Howard=20
>>
>> =20
> Yes. My point being that a std::tuple of std::unique_lock does *not*solve=
that problem. And that's what his multi-lock operation returns.
> =20
>
> Why do you think it doesn't works?
>
> Vicente
>
Oh, I missed the call to std::lock in your implementation. My fault.
--=20
------=_Part_734_13162230.1353444766095
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Tuesday, November 20, 2012 11:56:22 AM UTC-8, viboes wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 20/11/12 20:53, Nicol Bolas a
=E9crit :<br>
</div>
<blockquote type=3D"cite"><br>
<br>
On Tuesday, November 20, 2012 11:30:12 AM UTC-8, Howard Hinnant
wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex">On Nov 20,
2012, at 2:13 PM, Nicol Bolas <<a>jmck...@gmail.com</a>>
wrote:
<br>
<br>
> Also, there is a difficulty with multi-lock operations.
They all have to be done in the same order or else you can get
synchronization problems. If we're making a special function for
this, then it should help solve that problem by ordering the
mutexes in some way. Perhaps by using their addresses (since
mutex's can't be moved or copied) to order them.
<br>
<br>
std::lock(m1, m2, m3)'s job is to lock m1, m2 and m3 without
deadlock -- in whatever order they are supplied. The ordering
problem is already solved in the standard.
<br>
<br>
Howard
<br>
<br>
</blockquote>
<div><br>
Yes. My point being that a std::tuple of std::unique_lock does <i>n=
ot</i>
solve that problem. And that's what his multi-lock operation
returns.<br>
</div>
<br>
</blockquote>
Why do you think it doesn't works?<br>
<br>
Vicente<br></div></blockquote><div><br>Oh, I missed the call to std::lo=
ck in your implementation. My fault.<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_734_13162230.1353444766095--
.