Topic: Lambda based "lock_guard": std::locked
Author: Ben Craig <ben.craig@gmail.com>
Date: Tue, 13 Nov 2012 18:25:16 -0800 (PST)
Raw View
------=_Part_373_13048297.1352859916741
Content-Type: text/plain; charset=ISO-8859-1
I want to be able to do this in C++1y:
std::mutex m;
std::locked(m, [&]{
//modify shared state
});
Something like "std::locked" solves a problem I have seen many times.
People intend to write "std::lock_guard<std::mutex> lock(m);", but instead
write "std::lock_guard<std::mutex>(m);". The second construct locks and
immediately unlocks the mutex, protecting nothing. Ideally, compilers
would warn about unused temporary objects, but I haven't used a compiler
that does. With "std::locked", there is no need to name the guard.
It also solves an aesthetic issue. With std::locked, I don't need to name
the Lockable type every time I want to lock the object, where with
lock_guard, I get to mention the type repeatedly.
So here's the very rough implementation of std::locked:
template <typename Lockable, typename Func>
void locked(Lockable &lockable, Func func) {
lock_guard<Lockable> local_lock(lockable);
func();
}
Now, if we want to request a language feature, and not just a library
feature, it would be nice to have the variadic template version:
template <typename ...LockableN, typename Func>
void locked(LockableN &...lockableN, Func func) { //leading variadic
parameters not currently legal
std::lock(lockableN...);
try {func();}
catch(...) {std::unlock(lockableN...);} //std::unlock doesn't currently
exist
std::unlock(lockableN...);
}
But to be honest, I'd love to see the single lock version anyway. It is
likely I will be implementing the single lock version locally if it doesn't
become standardized.
--
------=_Part_373_13048297.1352859916741
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I want to be able to do this in C++1y:<br><br><div class=3D"prettyprint" st=
yle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 18=
7); border-style: solid; border-width: 1px; word-wrap: break-word;"><code c=
lass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">mutex m</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>std</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">lock=
ed</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">m</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">[&]{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br> </span><span style=3D"color: =
#800;" class=3D"styled-by-prettify">//modify shared state</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">});</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span></div></code></div><br>Somethi=
ng like "std::locked" solves a problem I have seen many times. People=
intend to write "std::lock_guard<std::mutex> lock(m);", but instead =
write "std::lock_guard<std::mutex>(m);". The second construct l=
ocks and immediately unlocks the mutex, protecting nothing. Ideally, =
compilers would warn about unused temporary objects, but I haven't used a c=
ompiler that does. With "std::locked", there is no need to name the g=
uard.<br><br>It also solves an aesthetic issue. With std::locked, I don't n=
eed to name the Lockable type every time I want to lock the object, where w=
ith lock_guard, I get to mention the type repeatedly.<br><br>So here's the =
very rough implementation of std::locked:<br><br><div class=3D"prettyprint"=
style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187,=
187); border-style: solid; border-width: 1px; word-wrap: break-word;"><cod=
e class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color:=
#008;" class=3D"styled-by-prettify">template</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-p=
rettify">Lockable</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #606;" class=3D"styled-by-prettify">Func</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> locked</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"sty=
led-by-prettify">Lockable</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>lockable</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">Func</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> func</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br> lock_guard</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #606;=
" class=3D"styled-by-prettify">Lockable</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> local_lock</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">lockable</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br> func</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span></div></code></div><br>Now, if we want to request a language feature,=
and not just a library feature, it would be nice to have the variadic temp=
late version:<br><div class=3D"prettyprint" style=3D"background-color: rgb(=
250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bord=
er-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">template</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">...</span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">LockableN</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Func</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">></span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> locke=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">LockableN</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&...</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">lockableN</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" =
class=3D"styled-by-prettify">Func</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> func</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #800;" class=3D"styled-by-prettify">//leading variadi=
c parameters not currently legal</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> std</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">::</span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">lock</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">lockableN</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">...);</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">try</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">func</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">();}</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">catch</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(...)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">unlock</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">lockableN</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">...);}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #800;" class=3D"styled-by-prettify">//std::unlo=
ck doesn't currently exist</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br> std</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">unlock</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">lockableN</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">...);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div=
></code></div><br>But to be honest, I'd love to see the single lock version=
anyway. It is likely I will be implementing the single lock version =
locally if it doesn't become standardized.<br>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_373_13048297.1352859916741--
.
Author: Anthony Williams <anthony.ajw@gmail.com>
Date: Wed, 14 Nov 2012 08:09:35 +0000
Raw View
On 14/11/12 02:25, Ben Craig wrote:
> I want to be able to do this in C++1y:
>
> |
> std::mutex m;
> std::locked(m,[&]{
> //modify shared state
> });
> |
That's an interesting idea. It's an example of the "Execute Around
Object" pattern, which is a nice counterpart to RAII.
I'm not sure "locked" is the right name. lock_and_call seems slightly
more appropriate, but unwieldy.
Anthony
--
Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/
just::thread C++11 thread library http://www.stdthread.co.uk
Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 14 Nov 2012 10:14:08 +0200
Raw View
On 14 November 2012 10:09, Anthony Williams <anthony.ajw@gmail.com> wrote:
> That's an interesting idea. It's an example of the "Execute Around
> Object" pattern, which is a nice counterpart to RAII.
> I'm not sure "locked" is the right name. lock_and_call seems slightly
> more appropriate, but unwieldy.
Bikeshed time! locked_call?
--
.
Author: Dean Michael Berris <dberris@google.com>
Date: Wed, 14 Nov 2012 19:18:03 +1100
Raw View
On Wed, Nov 14, 2012 at 7:14 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 14 November 2012 10:09, Anthony Williams <anthony.ajw@gmail.com> wrote:
>> That's an interesting idea. It's an example of the "Execute Around
>> Object" pattern, which is a nice counterpart to RAII.
>> I'm not sure "locked" is the right name. lock_and_call seems slightly
>> more appropriate, but unwieldy.
>
> Bikeshed time! locked_call?
>
How about "synchronized"? :P
--
Dean Michael Berris | Software Engineer
Google
--
.
Author: Ben Craig <ben.craig@gmail.com>
Date: Wed, 14 Nov 2012 05:23:20 -0800 (PST)
Raw View
------=_Part_753_24339542.1352899400591
Content-Type: text/plain; charset=ISO-8859-1
My preferred name is actually "std::lock", but that is already taken. If
someone braver, and more adept at variadic templates + sfinae wants to take
a stab at making an additional std::lock overload, then they are more than
welcome.
--
------=_Part_753_24339542.1352899400591
Content-Type: text/html; charset=ISO-8859-1
My preferred name is actually "std::lock", but that is already taken. If someone braver, and more adept at variadic templates + sfinae wants to take a stab at making an additional std::lock overload, then they are more than welcome.<br>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_753_24339542.1352899400591--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 14 Nov 2012 18:55:41 +0100
Raw View
This is a multi-part message in MIME format.
--------------070506040108020506050802
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 14/11/12 03:25, Ben Craig a =E9crit :
> I want to be able to do this in C++1y:
>
> |
> std::mutex m;
> std::locked(m,[&]{
> //modify shared state
> });
> |
>
> It also solves an aesthetic issue. With std::locked, I don't need to=20
> name the Lockable type every time I want to lock the object, where=20
> with lock_guard, I get to mention the type repeatedly.
Yes this is nice.
>
>
Your function seems to cover almost the same needs. For the function=20
name I would prefer std::synchronize. It would be great to do some=20
performances comparisons between std::locked and the direct use of=20
std::lock_guard.
I use to use a language-like macro.
#define synchronized(MUTEX) \
if (bool _stop_ =3D false) {} else \
for (std::lock_guard<decltype(MUTEX)>_lock_(MUTEX); =20
!_stop_; _stop_ =3D true)
The problems with the macro is that it introduces two new variables that=20
could conflict with user's variables. Is there a portable way to define=20
this macro avoiding these conflicting variables?
In addition the macro introduce a lot of boilerplate in order to ensure=20
that it works followed by a C++ statement. It would be great if we could=20
add new syntax to C++ using some kind of transformation.
synchronized(mtx)
//... STATEMENT
in
{
| lock_guard<||std::mutex>_lock_(mtx); // _lock_ should be a unique=20
identifier that doesn't conflicts with any other identifier.
|| //... STATEMENT
|}
Next follow the kind of information that will be needed to express this=20
transformation
@frame
@keyword synchronized// declares a new keyword
@grammar statement |=3D <synchronize-statement> // augment the current=20
definition of a statement
@grammar synchronize-statement ::=3D *synchronized* ( <expr:expression> )=
=20
<stmt:statement> // defines the new statement
@identifier _lock_// generates a unique identifier usable only in this=20
transformation
@transformation // defines the transformation
{
std::lock_guard<decltype($(expr))> _lock_($(expr));
$(stmt)
}
@end_frame
An external tool could do this kind of transformations, but it will be=20
so funny if this could be defined inside the C++ language. Of course,=20
this will be much more expensive than including in the language the=20
synchronize-statement directly.
Sorry for the digression.
Vicente
--=20
--------------070506040108020506050802
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DISO-8859-1"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 14/11/12 03:25, Ben Craig a éc=
rit :<br>
</div>
<blockquote
cite=3D"mid:6cb921d8-cf83-4eb3-95b1-026bd0e88e19@isocpp.org"
type=3D"cite">I want to be able to do this in C++1y:<br>
<br>
<div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,
250); border-color: rgb(187, 187, 187); border-style: solid;
border-width: 1px; word-wrap: break-word;"><code
class=3D"prettyprint">
<div class=3D"subprettyprint"><span style=3D"color: #000;"
class=3D"styled-by-prettify">std</span><span style=3D"color:
#660;" class=3D"styled-by-prettify">::</span><span
style=3D"color: #000;" class=3D"styled-by-prettify">mutex m</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
std</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">::</span><span style=3D"color:
#000;" class=3D"styled-by-prettify">locked</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span
style=3D"color: #000;" class=3D"styled-by-prettify">m</span><=
span
style=3D"color: #660;" class=3D"styled-by-prettify">,</span><=
span
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span
style=3D"color: #660;" class=3D"styled-by-prettify">[&]{<=
/span><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #800;"
class=3D"styled-by-prettify">//modify shared state</span><spa=
n
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">});</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
</span></div>
</code></div>
<br>
It also solves an aesthetic issue. With std::locked, I don't need
to name the Lockable type every time I want to lock the object,
where with lock_guard, I get to mention the type repeatedly.<br>
</blockquote>
Yes this is nice.<br>
<blockquote
cite=3D"mid:6cb921d8-cf83-4eb3-95b1-026bd0e88e19@isocpp.org"
type=3D"cite"> <br>
<br>
</blockquote>
Your function seems to cover almost the same needs. For the function
name I would prefer std::synchronize. It would be great to do some
performances comparisons between std::locked and the direct use of
std::lock_guard. <br>
<br>
I use to use a language-like macro. <br>
<br>
<meta http-equiv=3D"content-type" content=3D"text/html;
charset=3DISO-8859-1">
<pre class=3D"programlisting"><span class=3D"preprocessor">#define</spa=
n> <span class=3D"identifier">synchronized</span><span class=3D"special">(<=
/span><span class=3D"identifier">MUTEX</span><span class=3D"special">)</spa=
n> \
<span class=3D"keyword"> if</span> <span class=3D"special">(</span><span c=
lass=3D"keyword">bool</span> <span class=3D"identifier">_stop_</span> <span=
class=3D"special">=3D</span> <span class=3D"keyword">false</span><span cla=
ss=3D"special">)</span> <span class=3D"special">{}</span> <span class=3D"ke=
yword">else</span> <span class=3D"special">\</span>
<span class=3D"keyword"> for</span> <span class=3D"special">(std::lock_gua=
rd<decltype(MUTEX)> </span><span class=3D"identifier">_lock_</span><s=
pan class=3D"special">(</span><span class=3D"identifier">MUTEX</span><span =
class=3D"special">)</span><span class=3D"special">;</span> <span class=3D"s=
pecial">
!</span><span class=3D"identifier">_stop_</span><span class=3D"specia=
l">;</span> <span class=3D"identifier">_stop_</span> <span class=3D"special=
">=3D</span> <span class=3D"keyword">true</span><span class=3D"special">)</=
span></pre>
<br>
The problems with the macro is that it introduces two new variables
that could conflict with user's variables. Is there a portable way
to define this macro avoiding these conflicting variables? <br>
<br>
In addition the macro introduce a lot of boilerplate in order to
ensure that it works followed by a C++ statement. It would be great
if we could add new syntax to C++ using some kind of transformation.
<br>
<br>
synchronized(mtx) <br>
//... STATEMENT<br>
<br>
in <br>
<br>
{<br>
<code class=3D"prettyprint"><span style=3D"color: #000;"
class=3D"styled-by-prettify"> lock_guard</span><span
style=3D"color: #660;" class=3D"styled-by-prettify"><</span></co=
de><code
class=3D"prettyprint"><span style=3D"color: #660;"
class=3D"styled-by-prettify">std::mutex</span><span style=3D"color:
#660;" class=3D"styled-by-prettify">></span><span style=3D"color=
:
#000;" class=3D"styled-by-prettify"> _lock</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">_(</span>mtx<sp=
an
style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> // _lock=
_
should be a unique identifier that doesn't conflicts with any
other identifier.<br>
</span></code><code class=3D"prettyprint"><span style=3D"color: #000;=
"
class=3D"styled-by-prettify"> //... STATEMENT<br>
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span
style=3D"color: #660;" class=3D"styled-by-prettify"></span></code>}=
<br>
<br>
Next follow the kind of information that will be needed to express
this transformation<br>
<br>
<p class=3D"MsoNormal">@frame <o:p></o:p></p>
<p class=3D"MsoNormal">@keyword synchronized<o:p></o:p> // declares a
new keyword<br>
</p>
<p class=3D"MsoNormal">@grammar statement |=3D <synchronize-sta=
tement>
// augment the current definition of a statement<o:p></o:p></p>
<p class=3D"MsoNormal">@grammar synchronize-statement ::=3D <b>synchron=
ized</b>
( <expr:expression>
) <stmt:statement> // defines the new statement<o:p></o:p></p>
<p class=3D"MsoNormal">@identifier _lock_<o:p> // generates a unique
identifier usable only in this transformation<br>
</o:p></p>
@transformation // defines the transformation<br>
<p class=3D"MsoNormal"><o:p></o:p></p>
<span lang=3D"EN-US"> {<br>
std::lock_guard<decltyp=
e($(expr))> _lock_($(expr));<o:p></o:p></span>
<p class=3D"MsoNormal"><span lang=3D"EN-US"> &n=
bsp; $(stmt) <br>
}<o:p></o:p></span></p>
<span lang=3D"EN-US">@end_frame <br>
<br>
</span>An external tool could do this kind of transformations, but
it will be so funny if this could be defined inside the C++
language. Of course, this will be much more expensive than including
in the language the synchronize-statement directly.<br>
<br>
Sorry for the digression.<br>
Vicente<br>
<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------070506040108020506050802--
.
Author: korcan.hussein@googlemail.com
Date: Wed, 14 Nov 2012 15:05:25 -0800 (PST)
Raw View
------=_Part_1144_25908340.1352934325601
Content-Type: text/plain; charset=ISO-8859-1
>
> That's an interesting idea. It's an example of the "Execute Around
> Object" pattern, which is a nice counterpart to RAII.
>
In functional languages like Lisp, Scheme and Haskell these types of
higher-order functions are called *"with"* functions. In this particular
example such a function would be called something like *"with_lock"*.
Please lets try to avoid abusing terminology in C++ again, "functor" was
bad enough.
Generalizations of "with" functions for which all "with" functions can be
defined in terms of these are the functions typically called "bracket".
These general RAII style functions typically take 3 parameters; a
computation to run first ("acquire resource"), computation to run last
("release resource"), and finally the computation to run in-between.
I prefer with/bracket functions over C++ style RAII in some cases.
--
------=_Part_1144_25908340.1352934325601
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">That's an interesting idea. It=
's an example of the "Execute Around
<br>Object" pattern, which is a nice counterpart to RAII.
<br></blockquote><div><br>In functional languages like Lisp, Scheme and Has=
kell these types of higher-order functions are called <i>"with"</i> functio=
ns. In this particular example such a function would be called something li=
ke <i>"with_lock"</i>. Please lets try to avoid abusing terminology in C++ =
again, "functor" was bad enough.<br><br>Generalizations of "with" functions=
for which all "with" functions can be defined in terms of these are the fu=
nctions typically called "bracket". These general RAII style functions typi=
cally take 3 parameters; a computation to run first ("acquire resource"), c=
omputation to run last ("release resource"), and finally the computation to=
run in-between.<br><br>I prefer with/bracket functions over C++ style RAII=
in some cases.<br><br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_1144_25908340.1352934325601--
.
Author: korcan.hussein@googlemail.com
Date: Wed, 14 Nov 2012 15:24:37 -0800 (PST)
Raw View
------=_Part_1132_12443890.1352935477788
Content-Type: text/plain; charset=ISO-8859-1
You may also want to return a result from a "with" function, e.g:
#include <mutex>
template <typename Lockable, typename Function>
inline auto with_lock(Lockable &lockable, Function fn) -> decltype(fn())
{
std::lock_guard<Lockable> local_lock(lockable);
return fn();
}
//...
std::mutex m;
const bool result = with_lock(m, []() -> bool
{
// ...
return true;
});
--
------=_Part_1132_12443890.1352935477788
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
You may also want to return a result from a "with" function, e.g:<br><br><d=
iv class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bor=
der-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word=
-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><span style=3D"color: #800;" class=3D"styled-by-prettify">#include</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #080;" class=3D"styled-by-prettify"><mutex></span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">template</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Lockable</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">typename</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Funct=
ion</span><span style=3D"color: #660;" class=3D"styled-by-prettify">></s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">inline</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> with_lock</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #606;" c=
lass=3D"styled-by-prettify">Lockable</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">lockable</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Function=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> fn</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">-></span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">decltype</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">fn</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">())</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> &nbs=
p; std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">lock_guard</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">Lockable</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">></span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> local_lock</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">lockable</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> fn</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br><br></span><span style=3D"color: #800;" class=3D"styled-by-pretti=
fy">//...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">mutex m</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">bool</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> result </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> with_lock</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">m</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">[]()</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">-></span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">bool</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br> </span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">// ...</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">true</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">});</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></c=
ode></div><br><br>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_1132_12443890.1352935477788--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Thu, 15 Nov 2012 01:26:59 +0100
Raw View
--047d7b15a1ef95041e04ce7db59f
Content-Type: text/plain; charset=ISO-8859-1
Hi, do you mean
const bool result = with_lock(m, []() -> bool
{
// ...
return true;
})();
--
--047d7b15a1ef95041e04ce7db59f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi, do you mean<br><div class=3D"gmail_extra"><br></div><div class=3D"gmail=
_extra"><div style=3D"background-color:rgb(250,250,250);border:1px solid rg=
b(187,187,187);word-wrap:break-word"><code><span style=3D"color:rgb(0,0,136=
)">const</span>=A0<span style=3D"color:rgb(0,0,136)">bool</span>=A0result=
=A0<span style=3D"color:rgb(102,102,0)">=3D</span>=A0with_lock<span style=
=3D"color:rgb(102,102,0)">(</span>m<span style=3D"color:rgb(102,102,0)">,</=
span>=A0<span style=3D"color:rgb(102,102,0)">[]()</span>=A0<span style=3D"c=
olor:rgb(102,102,0)">-></span>=A0<span style=3D"color:rgb(0,0,136)">bool=
</span><br>
<span style=3D"color:rgb(102,102,0)">{</span><br>=A0 =A0=A0<span style=3D"c=
olor:rgb(136,0,0)">// ...</span><br>=A0 =A0=A0<span style=3D"color:rgb(0,0,=
136)">return</span>=A0<span style=3D"color:rgb(0,0,136)">true</span><span s=
tyle=3D"color:rgb(102,102,0)">;</span><br>
<span style=3D"color:rgb(102,102,0)">})()</span><font color=3D"#888888">;</=
font></code></div><span class=3D""><font color=3D"#888888"><br></font></spa=
n><br></div>
<p></p>
-- <br />
<br />
<br />
<br />
--047d7b15a1ef95041e04ce7db59f--
.
Author: korcan.hussein@googlemail.com
Date: Wed, 14 Nov 2012 16:35:55 -0800 (PST)
Raw View
------=_Part_1210_7954362.1352939755931
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Nah, with_lock is not returning a function, the function parameter is being=
=20
executed in with_lock and what ever the function parameter returns it will=
=20
be returned by with_lock. Maybe using a boolean return type as an example=
=20
was a bad example and confusing.
On Thursday, November 15, 2012 12:27:00 AM UTC, Klaim - Jo=EBl Lamotte wrot=
e:
>
> Hi, do you mean
>
> const bool result =3D with_lock(m, []() -> bool
> {
> // ...
> return true;
> })();
>
>
>
--=20
------=_Part_1210_7954362.1352939755931
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Nah, with_lock is not returning a function, the function parameter is being=
executed in with_lock and what ever the function parameter returns it will=
be returned by with_lock. Maybe using a boolean return type as an example =
was a bad example and confusing.<br><br>On Thursday, November 15, 2012 12:2=
7:00 AM UTC, Klaim - Jo=EBl Lamotte wrote:<blockquote class=3D"gmail_quote"=
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;">Hi, do you mean<br><div><br></div><div><div style=3D"background=
-color:rgb(250,250,250);border:1px solid rgb(187,187,187);word-wrap:break-w=
ord"><code><span style=3D"color:rgb(0,0,136)">const</span> <span style=
=3D"color:rgb(0,0,136)">bool</span> result <span style=3D"color:r=
gb(102,102,0)">=3D</span> with_lock<span style=3D"color:rgb(102,102,0)=
">(</span><wbr>m<span style=3D"color:rgb(102,102,0)">,</span> <span st=
yle=3D"color:rgb(102,102,0)">[]()</span> <span style=3D"color:rgb(102,=
102,0)">-></span> <span style=3D"color:rgb(0,0,136)">bool</span><br=
>
<span style=3D"color:rgb(102,102,0)">{</span><br> <span s=
tyle=3D"color:rgb(136,0,0)">// ...</span><br> <span style=
=3D"color:rgb(0,0,136)">return</span> <span style=3D"color:rgb(0,0,136=
)">true</span><span style=3D"color:rgb(102,102,0)">;</span><br>
<span style=3D"color:rgb(102,102,0)">})()</span><font color=3D"#888888">;</=
font></code></div><span><font color=3D"#888888"><br></font></span><br></div=
>
</blockquote>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_1210_7954362.1352939755931--
.
Author: Ben Craig <ben.craig@gmail.com>
Date: Wed, 14 Nov 2012 18:24:43 -0800 (PST)
Raw View
------=_Part_1276_31986484.1352946283055
Content-Type: text/plain; charset=ISO-8859-1
I like the name "with_lock", and I like the idea of allowing a return
type. Python also uses the "with" syntax.
I hadn't fully thought out returns within the callable function. Early
returns will make it more difficult for client code to switch from
lock_guards to with_lock, as the early return's behavior changes
substantially by putting it in a lambda. At least with the return type on
the with_lock function, they can still get information back out without
loading up on reference captures.
--
------=_Part_1276_31986484.1352946283055
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I like the name "with_lock", and I like the idea of allowing a return type.=
Python also uses the "with" syntax.<br><br>I hadn't fully thought ou=
t returns within the callable function. Early returns will make it mo=
re difficult for client code to switch from lock_guards to with_lock, as th=
e early return's behavior changes substantially by putting it in a lambda.&=
nbsp; At least with the return type on the with_lock function, they can sti=
ll get information back out without loading up on reference captures.<br>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_1276_31986484.1352946283055--
.
Author: stackmachine@hotmail.com
Date: Mon, 19 Nov 2012 13:38:28 -0800 (PST)
Raw View
------=_Part_201_31899115.1353361108428
Content-Type: text/plain; charset=ISO-8859-1
What if I want to use the lock in my function, e.g. with a
condition_variable? What if I don't want a std::lock_guard, but a
std::unique_lock, or something entirely different? What if I want to call
try_lock, try_lock_for or try_lock_until to be called, instead of .lock()?
--
------=_Part_201_31899115.1353361108428
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
What if I want to use the lock in my function, e.g. with a condition_variab=
le? What if I don't want a std::lock_guard, but a std::unique_lock, or some=
thing entirely different? What if I want to call try_lock, try_lock_for or =
try_lock_until to be called, instead of .lock()?
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_201_31899115.1353361108428--
.
Author: Ben Craig <ben.craig@gmail.com>
Date: Mon, 19 Nov 2012 16:30:39 -0800 (PST)
Raw View
------=_Part_145_1982376.1353371439559
Content-Type: text/plain; charset=ISO-8859-1
This doesn't attempt to solve those use cases, but they don't have the same
problems that the main std::lock_guard use case has. To reiterate from my
original post:
> Something like "std::locked" solves a problem I have seen many times.
> People intend to write "std::lock_guard<std::mutex> lock(m);", but instead
> write "std::lock_guard<std::mutex>(
> m);". The second construct locks and immediately unlocks the mutex,
> protecting nothing.
>
When using a condition_variable, or pretty much anything with a
std::unique_lock, you need a variable name. It is much harder to hit the
"unused temporary" problem when you actually need to call a function on the
object.
This does leave the aesthetic problem of mutex type repetition for
condition_variables and unique_locks. In my opinion, the best way to solve
those is with a core language feature. Something like this:
std::lock_guard<auto> lock(m); //template type deduced from constructor
argument type
//or even better...
std::lock_guard lock(m); //template in disguise.
Even if such a core language feature were present, I think with_lock would
make sense because of the unused temporary issue.
--
------=_Part_145_1982376.1353371439559
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
This doesn't attempt to solve those use cases, but they don't have the same=
problems that the main std::lock_guard use case has. To reiterate fr=
om my original post:<br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; bor=
der-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_=
quote">Something like "std::locked" solves a problem I have seen many times=
.. =20
People intend to write "std::lock_guard<std::mutex> lock(m);", but
instead write "std::lock_guard<std::mutex>(<div><wbr>m);". The=
second construct locks and immediately unlocks the mutex, protecting nothi=
ng.</div></blockquote>When using a condition_variable, or pretty much anyth=
ing with a std::unique_lock, you need a variable name. It is much har=
der to hit the "unused temporary" problem when you actually need to call a =
function on the object.<br><br>This does leave the aesthetic problem of mut=
ex type repetition for condition_variables and unique_locks. In my op=
inion, the best way to solve those is with a core language feature. S=
omething like this:<br><div class=3D"prettyprint" style=3D"background-color=
: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid=
; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by=
-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">lock=
_guard</span><span style=3D"color: #080;" class=3D"styled-by-prettify"><=
auto></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">lock</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">m</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">//template type deduced from constructor argument t=
ype</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #800;" class=3D"styled-by-prettify">//or even bet=
ter...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">lock_guard </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">lock</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">m</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D=
"styled-by-prettify">//template in disguise.</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span></div></code></div><br>Even if=
such a core language feature were present, I think with_lock would make se=
nse because of the unused temporary issue.<br><br>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_145_1982376.1353371439559--
.
Author: stackmachine@hotmail.com
Date: Mon, 19 Nov 2012 17:24:04 -0800 (PST)
Raw View
------=_Part_377_19716460.1353374644113
Content-Type: text/plain; charset=ISO-8859-1
Why not introduce something similar to Java's synchronized keyword instead?
synchronized(mutex)
{
// ...
}
// equivalent to:
{
std::lock_guard<decltype(mutex)> __lock;
// ...
}
This solves your problem nicely and clean, and has the following additional
advantages:
- No unneeded passing of parameters or return values
- Easier to use, less syntactic noise (ie. no lambda needed)
- Could be extended to solve mentioned use cases, for example:
synchronized(mutex, custom_lock<std::mutex> x)
{
// ...
}
// equivalent to
{
custom_lock<std::mutex> x(mutex);
// ...
}
--
------=_Part_377_19716460.1353374644113
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Why not introduce something similar to Java's synchronized keyword ins=
tead?<div><div style=3D"background-color: rgb(250, 250, 250); border: 1px s=
olid rgb(187, 187, 187); word-wrap: break-word;" class=3D"prettyprint"><cod=
e class=3D"prettyprint"><div class=3D"subprettyprint"><font color=3D"#66006=
6"><span style=3D"color: #008;" class=3D"styled-by-prettify">synchronized</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">mutex</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span></font><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #800;"=
class=3D"styled-by-prettify">// ...</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br><br></span><font color=3D"#666600"><span style=3D"color: #80=
0;" class=3D"styled-by-prettify">// equivalent to:</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br> std</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">lock_guard</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">decltype</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">mutex</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">)></span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> __lock</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nb=
sp; </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>// ...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><=
/font></div></code></div><br>This solves your problem nicely and clean, and=
has the following additional advantages:</div><div><ul><li><span style=3D"=
line-height: normal;">No unneeded passing of parameters or return values</s=
pan></li><li><span style=3D"line-height: normal;">Easier to use, less synta=
ctic noise (ie. no lambda needed)</span></li><li><span style=3D"line-height=
: normal;">Could be extended to solve mentioned use cases, for example:</sp=
an></li></ul><div><div style=3D"background-color: rgb(250, 250, 250); borde=
r: 1px solid rgb(187, 187, 187); word-wrap: break-word;" class=3D"prettypri=
nt"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">synchronized</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">mutex</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> custom_lock</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">mutex</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br> </span><span sty=
le=3D"color: #800;" class=3D"styled-by-prettify">// ...</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #800;"=
class=3D"styled-by-prettify">// equivalent to</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br> custom_lock</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">mutex</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">mutex</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br> </sp=
an><span style=3D"color: #800;" class=3D"styled-by-prettify">// ...</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code></d=
iv><br><br></div></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_377_19716460.1353374644113--
.
Author: stackmachine@hotmail.com
Date: Mon, 19 Nov 2012 17:29:07 -0800 (PST)
Raw View
------=_Part_429_14529532.1353374948019
Content-Type: text/plain; charset=ISO-8859-1
And also, an important point I forgot to mention: It is better visible in
source code and you can easily search for it.
--
------=_Part_429_14529532.1353374948019
Content-Type: text/html; charset=ISO-8859-1
And also, an important point I forgot to mention: It is better visible in source code and you can easily search for it.
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_429_14529532.1353374948019--
.
Author: Ben Craig <ben.craig@gmail.com>
Date: Mon, 19 Nov 2012 20:46:31 -0800 (PST)
Raw View
------=_Part_482_20486528.1353386791581
Content-Type: text/plain; charset=ISO-8859-1
It is my understanding that library solutions are preferred to core
language solutions, if they can be performed reasonably in the existing
core language. Getting a keyword added to the language is also pretty
difficult. Now to address some of the specific points:
* unnecessary parameter passing: I am under the (possibly mistaken)
impression that lambdas and template functions inline very well. In
release mode builds, I expect the generated assembly of my proposal to be
identical to the handwritten lock_guard approach. In the coming weeks, I
will try to validate this assumption with MSVC2012.
* syntactic noise: Yes, it is a bit more syntax, but not much in the void
return case. I count five extra characters (comma, semicolon, and [&]).
If a return type is needed, then there is significant noise.
* extension: with_unique_lock would be easy to propose as well, and that
could hand the unique_lock to the lambda. It doesn't involve standard
library extensions for arbitrary lock types, but the function that has been
proposed is five lines long. Maybe there's a way to get a truly generic
algorithm with template template parameters though.
* searchable: with_lock is just as searchable as synchronized, perhaps more
so since the term "with_lock" is less likely to show up in the comments of
legacy code.
--
------=_Part_482_20486528.1353386791581
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
It is my understanding that library solutions are preferred to core languag=
e solutions, if they can be performed reasonably in the existing core langu=
age. Getting a keyword added to the language is also pretty difficult=
.. Now to address some of the specific points:<br>* unnecessary parame=
ter passing: I am under the (possibly mistaken) impression that lambdas and=
template functions inline very well. In release mode builds, I expec=
t the generated assembly of my proposal to be identical to the handwritten =
lock_guard approach. In the coming weeks, I will try to validate this=
assumption with MSVC2012.<br>* syntactic noise: Yes, it is a bit mor=
e syntax, but not much in the void return case. I count five extra ch=
aracters (comma, semicolon, and [&]). If a return type is needed,=
then there is significant noise.<br> * extension: with_unique_lock wo=
uld be easy to propose as well, and that could hand the unique_lock to the =
lambda. It doesn't involve standard library extensions for arbitrary =
lock types, but the function that has been proposed is five lines long.&nbs=
p; Maybe there's a way to get a truly generic algorithm with template templ=
ate parameters though.<br>* searchable: with_lock is just as searchable as =
synchronized, perhaps more so since the term "with_lock" is less likely to =
show up in the comments of legacy code.<br>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_482_20486528.1353386791581--
.
Author: Jens Maurer <Jens.Maurer@gmx.net>
Date: Tue, 20 Nov 2012 08:31:37 +0100
Raw View
On 11/20/2012 02:24 AM, stackmachine@hotmail.com wrote:
> Why not introduce something similar to Java's synchronized keyword instead?
> synchronized(mutex)
> {
> // ...
> }
>
> // equivalent to:
> {
> std::lock_guard<decltype(mutex)>__lock;
> // ...
> }
C++ has a tendency to avoid core language extensions if a library
solution will do. range-for is one of the exceptions, but at least
it doesn't need a new keyword.
If a proposal like this comes before the committee, I'll vote against
it absent substantially more compelling reasons than what I've heard
so far.
Jens
--
.
Author: stackmachine@hotmail.com
Date: Tue, 20 Nov 2012 01:00:32 -0800 (PST)
Raw View
------=_Part_707_22159574.1353402032638
Content-Type: text/plain; charset=ISO-8859-1
Then IMO there is no point in adding a std::locked-Function, when I can get
something *more convenient* using a macro.
--
------=_Part_707_22159574.1353402032638
Content-Type: text/html; charset=ISO-8859-1
Then IMO there is no point in adding a std::locked-Function, when I can get something <u>more convenient</u> using a macro.<br>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_707_22159574.1353402032638--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 20 Nov 2012 20:12:48 +0100
Raw View
This is a multi-part message in MIME format.
--------------020100020405060305000109
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 15/11/12 00:24, korcan.hussein@googlemail.com a =E9crit :
> You may also want to return a result from a "with" function, e.g:
>
> |
> #include<mutex>
>
> template<typenameLockable,typenameFunction>
> inlineautowith_lock(Lockable&lockable,Functionfn)->decltype(fn())
> {
> std::lock_guard<Lockable>local_lock(lockable);
> returnfn();
> }
>
> //...
> std::mutex m;
> constboolresult =3Dwith_lock(m,[]()->bool
> {
> // ...
> returntrue;
> });
> |
>
>
I like the with_ proposal. I would like we compare to an alternative=20
using lock factories.
std::mutex m;
// ...
bool result;
{
auto lk =3D make_lock_guard(m) :
// ...
result =3D true
}
or using another lock
{
auto lk =3D make_unique_lock(m) :
// ...
}
or locking multiple locks at once (See my proposal for make_unique_locks=20
in another post).
{
auto lk =3D make_unique_locks(m1, m2, m3);
// ...
}
Note that lock_guard needs to be modified so that it can be created from=20
the result of make_lock_guard.
Vicente
--=20
--------------020100020405060305000109
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 15/11/12 00:24,
<a class="moz-txt-link-abbreviated" href="mailto:korcan.hussein@googlemail.com">korcan.hussein@googlemail.com</a> a écrit :<br>
</div>
<blockquote
cite="mid:ac6f04c7-f68b-4c9d-a87f-09216d5820c0@isocpp.org"
type="cite">You may also want to return a result from a "with"
function, e.g:<br>
<br>
<div class="prettyprint" style="background-color: rgb(250, 250,
250); border-color: rgb(187, 187, 187); border-style: solid;
border-width: 1px; word-wrap: break-word;"><code
class="prettyprint">
<div class="subprettyprint"><span style="color: #800;"
class="styled-by-prettify">#include</span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #080;" class="styled-by-prettify"><mutex></span><span
style="color: #000;" class="styled-by-prettify"><br>
<br>
</span><span style="color: #008;" class="styled-by-prettify">template</span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #660;" class="styled-by-prettify"><</span><span
style="color: #008;" class="styled-by-prettify">typename</span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #606;" class="styled-by-prettify">Lockable</span><span
style="color: #660;" class="styled-by-prettify">,</span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #008;" class="styled-by-prettify">typename</span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #606;" class="styled-by-prettify">Function</span><span
style="color: #660;" class="styled-by-prettify">></span><span
style="color: #000;" class="styled-by-prettify"><br>
</span><span style="color: #008;" class="styled-by-prettify">inline</span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #008;" class="styled-by-prettify">auto</span><span
style="color: #000;" class="styled-by-prettify"> with_lock</span><span
style="color: #660;" class="styled-by-prettify">(</span><span
style="color: #606;" class="styled-by-prettify">Lockable</span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #660;" class="styled-by-prettify">&</span><span
style="color: #000;" class="styled-by-prettify">lockable</span><span
style="color: #660;" class="styled-by-prettify">,</span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #606;" class="styled-by-prettify">Function</span><span
style="color: #000;" class="styled-by-prettify"> fn</span><span
style="color: #660;" class="styled-by-prettify">)</span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #660;" class="styled-by-prettify">-></span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #008;" class="styled-by-prettify">decltype</span><span
style="color: #660;" class="styled-by-prettify">(</span><span
style="color: #000;" class="styled-by-prettify">fn</span><span
style="color: #660;" class="styled-by-prettify">())</span><span
style="color: #000;" class="styled-by-prettify"><br>
</span><span style="color: #660;" class="styled-by-prettify">{</span><span
style="color: #000;" class="styled-by-prettify"><br>
std</span><span style="color: #660;"
class="styled-by-prettify">::</span><span style="color:
#000;" class="styled-by-prettify">lock_guard</span><span
style="color: #660;" class="styled-by-prettify"><</span><span
style="color: #606;" class="styled-by-prettify">Lockable</span><span
style="color: #660;" class="styled-by-prettify">></span><span
style="color: #000;" class="styled-by-prettify">
local_lock</span><span style="color: #660;"
class="styled-by-prettify">(</span><span style="color:
#000;" class="styled-by-prettify">lockable</span><span
style="color: #660;" class="styled-by-prettify">);</span><span
style="color: #000;" class="styled-by-prettify"><br>
</span><span style="color: #008;"
class="styled-by-prettify">return</span><span
style="color: #000;" class="styled-by-prettify"> fn</span><span
style="color: #660;" class="styled-by-prettify">();</span><span
style="color: #000;" class="styled-by-prettify"><br>
</span><span style="color: #660;" class="styled-by-prettify">}</span><span
style="color: #000;" class="styled-by-prettify"><br>
<br>
</span><span style="color: #800;" class="styled-by-prettify">//...</span><span
style="color: #000;" class="styled-by-prettify"><br>
std</span><span style="color: #660;"
class="styled-by-prettify">::</span><span style="color:
#000;" class="styled-by-prettify">mutex m</span><span
style="color: #660;" class="styled-by-prettify">;</span><span
style="color: #000;" class="styled-by-prettify"><br>
</span><span style="color: #008;" class="styled-by-prettify">const</span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #008;" class="styled-by-prettify">bool</span><span
style="color: #000;" class="styled-by-prettify"> result </span><span
style="color: #660;" class="styled-by-prettify">=</span><span
style="color: #000;" class="styled-by-prettify"> with_lock</span><span
style="color: #660;" class="styled-by-prettify">(</span><span
style="color: #000;" class="styled-by-prettify">m</span><span
style="color: #660;" class="styled-by-prettify">,</span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #660;" class="styled-by-prettify">[]()</span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #660;" class="styled-by-prettify">-></span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #008;" class="styled-by-prettify">bool</span><span
style="color: #000;" class="styled-by-prettify"><br>
</span><span style="color: #660;" class="styled-by-prettify">{</span><span
style="color: #000;" class="styled-by-prettify"><br>
</span><span style="color: #800;"
class="styled-by-prettify">// ...</span><span
style="color: #000;" class="styled-by-prettify"><br>
</span><span style="color: #008;"
class="styled-by-prettify">return</span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #008;" class="styled-by-prettify">true</span><span
style="color: #660;" class="styled-by-prettify">;</span><span
style="color: #000;" class="styled-by-prettify"><br>
</span><span style="color: #660;" class="styled-by-prettify">});</span><span
style="color: #000;" class="styled-by-prettify"><br>
</span></div>
</code></div>
<br>
<br>
</blockquote>
I like the with_ proposal. I would like we compare to an alternative
using lock factories.<br>
<br>
std::mutex m;<br>
// ...<br>
bool result;<br>
{<br>
auto lk = make_lock_guard(m) :<br>
// ...<br>
result = true<br>
}<br>
<br>
or using another lock<br>
<br>
{<br>
auto lk = make_unique_lock(m) :<br>
// ...<br>
}<br>
<br>
or locking multiple locks at once (See my proposal for
make_unique_locks in another post).<br>
<br>
{<br>
auto lk = make_unique_locks(m1, m2, m3);<br>
// ...<br>
}<br>
<br>
Note that lock_guard needs to be modified so that it can be created
from the result of make_lock_guard.<br>
<br>
Vicente<br>
<br>
<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------020100020405060305000109--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Tue, 20 Nov 2012 14:26:18 -0500
Raw View
On Nov 20, 2012, at 2:12 PM, "Vicente J. Botet Escriba" <vicente.botet@wana=
doo.fr> wrote:
> I like the with_ proposal. I would like we compare to an alternative usin=
g lock factories.
>=20
> std::mutex m;
> // ...
> bool result;
> {
> auto lk =3D make_lock_guard(m) :
> // ...
> result =3D true
> }
<snip>
> Note that lock_guard needs to be modified so that it can be created from =
the result of make_lock_guard.
Once you add a move constructor to lock_guard it becomes virtually indistin=
guishable from unique_lock. It would loose its raison d'=EAtre.
Howard
--=20
.
Author: pubby8@gmail.com
Date: Tue, 20 Nov 2012 12:09:47 -0800 (PST)
Raw View
------=_Part_239_14445490.1353442187481
Content-Type: text/plain; charset=ISO-8859-1
This might be a silly idea, but lock_guard could have a call member which
did the same thing:
std::lock_guard<std::mutex>(m).call([&](){ ... });
Also, the variadic version could be implemented recursively:
template<typename Func, typename Lockable, typename... Lockables>
void locked(Func func, Lockable lock, Lockables... lockables) {
lock_guard<Lockable> local_lock(lockable);
locked(func, lockables...);
}
--
------=_Part_239_14445490.1353442187481
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
This might be a silly idea, but lock_guard could have a call member which d=
id the same thing:<br><br>std::lock_guard<std::mutex>(m).call([&]=
(){ ... });<div><br></div><div>Also, the variadic version could be implemen=
ted recursively:<br><div><br></div><div>template<typename Func, typename=
Lockable, typename... Lockables></div><div>void locked(Func func, Locka=
ble lock, Lockables... lockables) {<br> lock_guard<Lockable=
> local_lock(lockable);</div><div> locked(func, lockables..=
..);<br>}</div></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_239_14445490.1353442187481--
.
Author: pubby8@gmail.com
Date: Tue, 20 Nov 2012 12:12:46 -0800 (PST)
Raw View
------=_Part_6_12255382.1353442366702
Content-Type: text/plain; charset=ISO-8859-1
Actually, there's probably a deadlock in that recursive one so I'll take
back what I said.
--
------=_Part_6_12255382.1353442366702
Content-Type: text/html; charset=ISO-8859-1
Actually, there's probably a deadlock in that recursive one so I'll take back what I said.
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_6_12255382.1353442366702--
.
Author: Alberto Ganesh Barbati <albertobarbati@gmail.com>
Date: Tue, 20 Nov 2012 22:34:30 +0100
Raw View
--Apple-Mail=_E0266F32-72D5-4741-A86D-65BDE2E05A40
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
Il giorno 20/nov/2012, alle ore 20:12, Vicente J. Botet Escriba <vicente.bo=
tet@wanadoo.fr> ha scritto:
> Le 15/11/12 00:24, korcan.hussein@googlemail.com a =E9crit :
>> You may also want to return a result from a "with" function, e.g:
>>=20
>> #include <mutex>
>>=20
>> template <typename Lockable, typename Function>
>> inline auto with_lock(Lockable &lockable, Function fn) -> decltype(fn())
>> {
>> std::lock_guard<Lockable> local_lock(lockable);
>> return fn();
>> }
>>=20
>> //...
>> std::mutex m;
>> const bool result =3D with_lock(m, []() -> bool
>> {
>> // ...
>> return true;
>> });
>>=20
>>=20
> I like the with_ proposal. I would like we compare to an alternative usin=
g lock factories.
>=20
> std::mutex m;
> // ...
> bool result;
> {
> auto lk =3D make_lock_guard(m) :
> // ...
> result =3D true
> }
>=20
> or using another lock
>=20
> {
> auto lk =3D make_unique_lock(m) :
> // ...
> }
>=20
> or locking multiple locks at once (See my proposal for make_unique_locks =
in another post).
>=20
> {
> auto lk =3D make_unique_locks(m1, m2, m3);
> // ...
> }
>=20
> Note that lock_guard needs to be modified so that it can be created from =
the result of make_lock_guard.
Just write it like this:
auto&& lk =3D make_lock_guard(m);
and you won't need to modify lock_guard.
Ganesh
--=20
--Apple-Mail=_E0266F32-72D5-4741-A86D-65BDE2E05A40
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Diso-8859-1"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mo=
de: space; -webkit-line-break: after-white-space; "><br><div><div>Il giorno=
20/nov/2012, alle ore 20:12, Vicente J. Botet Escriba <<a href=3D"mailt=
o:vicente.botet@wanadoo.fr">vicente.botet@wanadoo.fr</a>> ha scritto:</d=
iv><br class=3D"Apple-interchange-newline"><blockquote type=3D"cite">
=20
<meta content=3D"text/html; charset=3DISO-8859-1" http-equiv=3D"Content=
-Type">
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 15/11/12 00:24,
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:korcan.hussein@g=
ooglemail.com">korcan.hussein@googlemail.com</a> a =E9crit :<br>
</div>
<blockquote cite=3D"mid:ac6f04c7-f68b-4c9d-a87f-09216d5820c0@isocpp.org=
" type=3D"cite">You may also want to return a result from a "with"
function, e.g:<br>
<br>
<div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,
250); border-color: rgb(187, 187, 187); border-style: solid;
border-width: 1px; word-wrap: break-word;"><code class=3D"prettypri=
nt">
<div class=3D"subprettyprint"><span style=3D"color: #800;" class=
=3D"styled-by-prettify">#include</span><span style=3D"" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify"=
><mutex></span><span style=3D"" class=3D"styled-by-prettify"><br>
<br>
</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">template</span><span style=3D"" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span style=
=3D"" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">Lockable</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">typena=
me</span><span style=3D"" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Function</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D"" =
class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">inline</span><span style=3D"" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=
=3D"" class=3D"styled-by-prettify"> with_lock</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">Lockable</span><span style=3D"" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&</span><span style=3D"" class=3D"styled-by-prettify">lockable</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" =
class=3D"styled-by-prettify">Function</span><span style=3D"" class=3D"style=
d-by-prettify"> fn</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">)</span><span style=3D"" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">-></span><span styl=
e=3D"" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">decltype</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"" class=3D"styled-by-pretti=
fy">fn</span><span style=3D"color: #660;" class=3D"styled-by-prettify">())<=
/span><span style=3D"" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">{</span><span style=3D"" class=3D"styled-by-prettify"><br>
std</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">::</span><span style=3D"" class=3D"styled-by-prettify"=
>lock_guard</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
><</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Locka=
ble</span><span style=3D"color: #660;" class=3D"styled-by-prettify">></s=
pan><span style=3D"" class=3D"styled-by-prettify">
local_lock</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"" class=3D"styled-by-prettify">lockabl=
e</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span>=
<span style=3D"" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">return</span><span style=3D"" class=3D"styled-by-prettify=
"> fn</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</=
span><span style=3D"" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">}</span><span style=3D"" class=3D"styled-by-prettify"><br>
<br>
</span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">//...</span><span style=3D"" class=3D"styled-by-prettify"><br>
std</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">::</span><span style=3D"" class=3D"styled-by-prettify">mutex m</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span st=
yle=3D"" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">const</span><span style=3D"" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span style=
=3D"" class=3D"styled-by-prettify"> result </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">=3D</span><span style=3D"" class=3D"styled=
-by-prettify"> with_lock</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"" class=3D"styled-by-prettify">m</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">[]()</span><span style=3D"" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">-></span><span style=3D"" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span style=
=3D"" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">{</span><span style=3D"" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">// ...</span><span style=3D"" class=3D"styled-by-prettify=
"><br>
</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">return</span><span style=3D"" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">true</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span=
style=3D"" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">});</span><span style=3D"" class=3D"styled-by-prettify"><br>
</span></div>
</code></div>
<br>
<br>
</blockquote>
I like the with_ proposal. I would like we compare to an alternative
using lock factories.<br>
<br>
std::mutex m;<br>
// ...<br>
bool result;<br>
{<br>
auto lk =3D make_lock_guard(m) :<br>
// ...<br>
result =3D true<br>
}<br>
<br>
or using another lock<br>
<br>
{<br>
auto lk =3D make_unique_lock(m) :<br>
// ...<br>
}<br>
<br>
or locking multiple locks at once (See my proposal for
make_unique_locks in another post).<br>
<br>
{<br>
auto lk =3D make_unique_locks(m1, m2, m3=
);<br>
// ...<br>
}<br>
<br>
Note that lock_guard needs to be modified so that it can be created
from the result of make_lock_guard.<br></div></blockquote><br></div><di=
v>Just write it like this:</div><div><br></div><div> au=
to&& lk =3D make_lock_guard(m);</div><div><br></div><div>and y=
ou won't need to modify lock_guard.</div><div><br></div><div>Ganesh</div><d=
iv><br></div></body></html>
<p></p>
-- <br />
<br />
<br />
<br />
--Apple-Mail=_E0266F32-72D5-4741-A86D-65BDE2E05A40--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 20 Nov 2012 23:07:05 +0100
Raw View
Le 20/11/12 20:26, Howard Hinnant a =E9crit :
> On Nov 20, 2012, at 2:12 PM, "Vicente J. Botet Escriba" <vicente.botet@wa=
nadoo.fr> wrote:
>
>> I like the with_ proposal. I would like we compare to an alternative usi=
ng lock factories.
>>
>> std::mutex m;
>> // ...
>> bool result;
>> {
>> auto lk =3D make_lock_guard(m) :
>> // ...
>> result =3D true
>> }
> <snip>
>
>> Note that lock_guard needs to be modified so that it can be created from=
the result of make_lock_guard.
> Once you add a move constructor to lock_guard it becomes virtually indist=
inguishable from unique_lock. It would loose its raison d'=EAtre.
>
> Howard
>
Hrr, you are right. We can not get
auto lk =3D make_lock_guard(m);
without making lock_guard movable.
make_lock_guard could return something hidden that behaves as a lock_guard =
and is movable. Would this be acceptable if there is no performance degrada=
tion?
Vicente
--=20
.
Author: Jeffrey Yasskin <jyasskin@googlers.com>
Date: Tue, 20 Nov 2012 14:15:40 -0800
Raw View
On Tue, Nov 20, 2012 at 2:07 PM, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
> Le 20/11/12 20:26, Howard Hinnant a =E9crit :
>
>> On Nov 20, 2012, at 2:12 PM, "Vicente J. Botet Escriba"
>> <vicente.botet@wanadoo.fr> wrote:
>>
>>> I like the with_ proposal. I would like we compare to an alternative
>>> using lock factories.
>>>
>>> std::mutex m;
>>> // ...
>>> bool result;
>>> {
>>> auto lk =3D make_lock_guard(m) :
>>> // ...
>>> result =3D true
>>> }
>>
>> <snip>
>>
>>> Note that lock_guard needs to be modified so that it can be created fro=
m
>>> the result of make_lock_guard.
>>
>> Once you add a move constructor to lock_guard it becomes virtually
>> indistinguishable from unique_lock. It would loose its raison d'=EAtre.
>>
>> Howard
>>
> Hrr, you are right. We can not get
>
> auto lk =3D make_lock_guard(m);
>
> without making lock_guard movable.
>
> make_lock_guard could return something hidden that behaves as a lock_guar=
d
> and is movable. Would this be acceptable if there is no performance
> degradation?
I believe unique_lock will perform the same as lock_guard if you use
it simply and with an optimizing compiler. It would be interesting to
see benchmarks or assembly dumps showing otherwise, but assuming it
does perform the same, I'd just skip make_lock_guard and have people
use make_unique_lock(). They can use "const auto lk" if they want to
declare to readers that they never modify the unique_lock.
I'd also support a proposal to make something like:
auto __ =3D make_unique_lock(m1);
auto __ =3D make_unique_lock(m2);
work. (Note that I've used the same variable name twice there. "__"
would denote an explicitly unused variable so that its name can be
re-used. "_" would be better, but it's not currently reserved. This
also means we don't need the 'const' since it's impossible to refer to
the variable later.)
Jeffrey
--=20
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 21 Nov 2012 00:02:38 +0100
Raw View
This is a multi-part message in MIME format.
--------------030507010805050205030405
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 20/11/12 22:34, Alberto Ganesh Barbati a =E9crit :
>
> Il giorno 20/nov/2012, alle ore 20:12, Vicente J. Botet Escriba=20
> <vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>> ha scritto:
>
>> Le 15/11/12 00:24, korcan.hussein@googlemail.com a =E9crit :
>>> You may also want to return a result from a "with" function, e.g:
>>>
>>> |
>>> #include<mutex>
>>>
>>> template<typenameLockable,typenameFunction>
>>> inlineautowith_lock(Lockable&lockable,Functionfn)->decltype(fn())
>>> {
>>> std::lock_guard<Lockable>local_lock(lockable);
>>> returnfn();
>>> }
>>>
>>> //...
>>> std::mutex m;
>>> constboolresult =3Dwith_lock(m,[]()->bool
>>> {
>>> // ...
>>> returntrue;
>>> });
>>> |
>>>
>>>
>> I like the with_ proposal. I would like we compare to an alternative=20
>> using lock factories.
>>
>> std::mutex m;
>> // ...
>> bool result;
>> {
>> auto lk =3D make_lock_guard(m) :
>> // ...
>> result =3D true
>> }
>>
>> or using another lock
>>
>> {
>> auto lk =3D make_unique_lock(m) :
>> // ...
>> }
>>
>> or locking multiple locks at once (See my proposal for=20
>> make_unique_locks in another post).
>>
>> {
>> auto lk =3D make_unique_locks(m1, m2, m3);
>> // ...
>> }
>>
>> Note that lock_guard needs to be modified so that it can be created=20
>> from the result of make_lock_guard.
>
> Just write it like this:
>
> auto&& lk =3D make_lock_guard(m);
>
> and you won't need to modify lock_guard.
>
>
Thanks for the hint. I've declared make_lock_guard as
template <typename Lockable>
lock_guard<Lockable>&& make_lock_guard(Lockable& mtx);
and I'm getting a warning:
.../../../boost/thread/lock_guard.hpp:59:12: warning: returning reference=20
to local temporary object [-Wreturn-stack-address]
return lock_guard<Lockable>(mtx);
which seems correct to me.
Is this the correct way to declare it?
Vicente
--=20
--------------030507010805050205030405
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 22:34, Alberto Ganesh
Barbati a écrit :<br>
</div>
<blockquote
cite="mid:1D06D498-232C-4745-89ED-25BB4B1B8C6C@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>Il giorno 20/nov/2012, alle ore 20:12, Vicente J. Botet
Escriba <<a moz-do-not-send="true"
href="mailto:vicente.botet@wanadoo.fr">vicente.botet@wanadoo.fr</a>>
ha scritto:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 15/11/12 00:24, <a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:korcan.hussein@googlemail.com">korcan.hussein@googlemail.com</a>
a écrit :<br>
</div>
<blockquote
cite="mid:ac6f04c7-f68b-4c9d-a87f-09216d5820c0@isocpp.org"
type="cite">You may also want to return a result from a
"with" function, e.g:<br>
<br>
<div class="prettyprint" style="background-color: rgb(250,
250, 250); border-color: rgb(187, 187, 187);
border-style: solid; border-width: 1px; word-wrap:
break-word;"><code class="prettyprint">
<div class="subprettyprint"><span style="color: #800;"
class="styled-by-prettify">#include</span><span
style="" class="styled-by-prettify"> </span><span
style="color: #080;" class="styled-by-prettify"><mutex></span><span
style="" class="styled-by-prettify"><br>
<br>
</span><span style="color: #008;"
class="styled-by-prettify">template</span><span
style="" class="styled-by-prettify"> </span><span
style="color: #660;" class="styled-by-prettify"><</span><span
style="color: #008;" class="styled-by-prettify">typename</span><span
style="" class="styled-by-prettify"> </span><span
style="color: #606;" class="styled-by-prettify">Lockable</span><span
style="color: #660;" class="styled-by-prettify">,</span><span
style="" class="styled-by-prettify"> </span><span
style="color: #008;" class="styled-by-prettify">typename</span><span
style="" class="styled-by-prettify"> </span><span
style="color: #606;" class="styled-by-prettify">Function</span><span
style="color: #660;" class="styled-by-prettify">></span><span
style="" class="styled-by-prettify"><br>
</span><span style="color: #008;"
class="styled-by-prettify">inline</span><span
style="" class="styled-by-prettify"> </span><span
style="color: #008;" class="styled-by-prettify">auto</span><span
style="" class="styled-by-prettify"> with_lock</span><span
style="color: #660;" class="styled-by-prettify">(</span><span
style="color: #606;" class="styled-by-prettify">Lockable</span><span
style="" class="styled-by-prettify"> </span><span
style="color: #660;" class="styled-by-prettify">&</span><span
style="" class="styled-by-prettify">lockable</span><span
style="color: #660;" class="styled-by-prettify">,</span><span
style="" class="styled-by-prettify"> </span><span
style="color: #606;" class="styled-by-prettify">Function</span><span
style="" class="styled-by-prettify"> fn</span><span
style="color: #660;" class="styled-by-prettify">)</span><span
style="" class="styled-by-prettify"> </span><span
style="color: #660;" class="styled-by-prettify">-></span><span
style="" class="styled-by-prettify"> </span><span
style="color: #008;" class="styled-by-prettify">decltype</span><span
style="color: #660;" class="styled-by-prettify">(</span><span
style="" class="styled-by-prettify">fn</span><span
style="color: #660;" class="styled-by-prettify">())</span><span
style="" class="styled-by-prettify"><br>
</span><span style="color: #660;"
class="styled-by-prettify">{</span><span style=""
class="styled-by-prettify"><br>
std</span><span style="color: #660;"
class="styled-by-prettify">::</span><span style=""
class="styled-by-prettify">lock_guard</span><span
style="color: #660;" class="styled-by-prettify"><</span><span
style="color: #606;" class="styled-by-prettify">Lockable</span><span
style="color: #660;" class="styled-by-prettify">></span><span
style="" class="styled-by-prettify"> local_lock</span><span
style="color: #660;" class="styled-by-prettify">(</span><span
style="" class="styled-by-prettify">lockable</span><span
style="color: #660;" class="styled-by-prettify">);</span><span
style="" class="styled-by-prettify"><br>
</span><span style="color: #008;"
class="styled-by-prettify">return</span><span
style="" class="styled-by-prettify"> fn</span><span
style="color: #660;" class="styled-by-prettify">();</span><span
style="" class="styled-by-prettify"><br>
</span><span style="color: #660;"
class="styled-by-prettify">}</span><span style=""
class="styled-by-prettify"><br>
<br>
</span><span style="color: #800;"
class="styled-by-prettify">//...</span><span
style="" class="styled-by-prettify"><br>
std</span><span style="color: #660;"
class="styled-by-prettify">::</span><span style=""
class="styled-by-prettify">mutex m</span><span
style="color: #660;" class="styled-by-prettify">;</span><span
style="" class="styled-by-prettify"><br>
</span><span style="color: #008;"
class="styled-by-prettify">const</span><span
style="" class="styled-by-prettify"> </span><span
style="color: #008;" class="styled-by-prettify">bool</span><span
style="" class="styled-by-prettify"> result </span><span
style="color: #660;" class="styled-by-prettify">=</span><span
style="" class="styled-by-prettify"> with_lock</span><span
style="color: #660;" class="styled-by-prettify">(</span><span
style="" class="styled-by-prettify">m</span><span
style="color: #660;" class="styled-by-prettify">,</span><span
style="" class="styled-by-prettify"> </span><span
style="color: #660;" class="styled-by-prettify">[]()</span><span
style="" class="styled-by-prettify"> </span><span
style="color: #660;" class="styled-by-prettify">-></span><span
style="" class="styled-by-prettify"> </span><span
style="color: #008;" class="styled-by-prettify">bool</span><span
style="" class="styled-by-prettify"><br>
</span><span style="color: #660;"
class="styled-by-prettify">{</span><span style=""
class="styled-by-prettify"><br>
</span><span style="color: #800;"
class="styled-by-prettify">// ...</span><span
style="" class="styled-by-prettify"><br>
</span><span style="color: #008;"
class="styled-by-prettify">return</span><span
style="" class="styled-by-prettify"> </span><span
style="color: #008;" class="styled-by-prettify">true</span><span
style="color: #660;" class="styled-by-prettify">;</span><span
style="" class="styled-by-prettify"><br>
</span><span style="color: #660;"
class="styled-by-prettify">});</span><span
style="" class="styled-by-prettify"><br>
</span></div>
</code></div>
<br>
<br>
</blockquote>
I like the with_ proposal. I would like we compare to an
alternative using lock factories.<br>
<br>
std::mutex m;<br>
// ...<br>
bool result;<br>
{<br>
auto lk = make_lock_guard(m) :<br>
// ...<br>
result = true<br>
}<br>
<br>
or using another lock<br>
<br>
{<br>
auto lk = make_unique_lock(m) :<br>
// ...<br>
}<br>
<br>
or locking multiple locks at once (See my proposal for
make_unique_locks in another post).<br>
<br>
{<br>
auto lk = make_unique_locks(m1, m2, m3);<br>
// ...<br>
}<br>
<br>
Note that lock_guard needs to be modified so that it can be
created from the result of make_lock_guard.<br>
</div>
</blockquote>
<br>
</div>
<div>Just write it like this:</div>
<div><br>
</div>
<div> auto&& lk = make_lock_guard(m);</div>
<div><br>
</div>
<div>and you won't need to modify lock_guard.</div>
<div><br>
</div>
<br>
</blockquote>
Thanks for the hint. I've declared make_lock_guard as<br>
<br>
template <typename Lockable><br>
lock_guard<Lockable>&& make_lock_guard(Lockable&
mtx);<br>
<br>
and I'm getting a warning:<br>
../../../boost/thread/lock_guard.hpp:59:12: warning: returning
reference to local temporary object [-Wreturn-stack-address]<br>
return lock_guard<Lockable>(mtx);<br>
<br>
which seems correct to me.<br>
<br>
Is this the correct way to declare it?<br>
<br>
Vicente<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------030507010805050205030405--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 21 Nov 2012 00:09:04 +0100
Raw View
Le 20/11/12 23:15, Jeffrey Yasskin a =E9crit :
> On Tue, Nov 20, 2012 at 2:07 PM, Vicente J. Botet Escriba
> <vicente.botet@wanadoo.fr> wrote:
>> Le 20/11/12 20:26, Howard Hinnant a =E9crit :
>>
>>> On Nov 20, 2012, at 2:12 PM, "Vicente J. Botet Escriba"
>>> <vicente.botet@wanadoo.fr> wrote:
>>>
>>>> I like the with_ proposal. I would like we compare to an alternative
>>>> using lock factories.
>>>>
>>>> std::mutex m;
>>>> // ...
>>>> bool result;
>>>> {
>>>> auto lk =3D make_lock_guard(m) :
>>>> // ...
>>>> result =3D true
>>>> }
>>> <snip>
>>>
>>>> Note that lock_guard needs to be modified so that it can be created fr=
om
>>>> the result of make_lock_guard.
>>> Once you add a move constructor to lock_guard it becomes virtually
>>> indistinguishable from unique_lock. It would loose its raison d'=EAtre=
..
>>>
>>> Howard
>>>
>> Hrr, you are right. We can not get
>>
>> auto lk =3D make_lock_guard(m);
>>
>> without making lock_guard movable.
>>
>> make_lock_guard could return something hidden that behaves as a lock_gua=
rd
>> and is movable. Would this be acceptable if there is no performance
>> degradation?
> I believe unique_lock will perform the same as lock_guard if you use
> it simply and with an optimizing compiler. It would be interesting to
> see benchmarks or assembly dumps showing otherwise, but assuming it
> does perform the same, I'd just skip make_lock_guard and have people
> use make_unique_lock(). They can use "const auto lk" if they want to
> declare to readers that they never modify the unique_lock.
It seems that Alberto has found a way to make it work.
auto&& lk =3D make_lock_guard(m);
> I'd also support a proposal to make something like:
> auto __ =3D make_unique_lock(m1);
> auto __ =3D make_unique_lock(m2);
> work. (Note that I've used the same variable name twice there. "__"
> would denote an explicitly unused variable so that its name can be
> re-used. "_" would be better, but it's not currently reserved. This
> also means we don't need the 'const' since it's impossible to refer to
> the variable later.)
I have suggested the use of ... on other threads to name a unique and=20
anonymous variable.
auto&& ... =3D make_lock_guard(m);
Vicente
--=20
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Tue, 20 Nov 2012 19:47:46 -0500
Raw View
On Nov 20, 2012, at 6:02 PM, "Vicente J. Botet Escriba" <vicente.botet@wana=
doo.fr> wrote:
> Le 20/11/12 22:34, Alberto Ganesh Barbati a =E9crit :
>>=20
>> Il giorno 20/nov/2012, alle ore 20:12, Vicente J. Botet Escriba <vicente=
..botet@wanadoo.fr> ha scritto:
>>=20
>>> Le 15/11/12 00:24, korcan.hussein@googlemail.com a =E9crit :
>>>> You may also want to return a result from a "with" function, e.g:
>>>>=20
>>>> #include <mutex>
>>>>=20
>>>> template <typename Lockable, typename Function>
>>>> inline auto with_lock(Lockable &lockable, Function fn) -> decltype(fn(=
))
>>>> {
>>>> std::lock_guard<Lockable> local_lock(lockable);
>>>> return fn();
>>>> }
>>>>=20
>>>> //...
>>>> std::mutex m;
>>>> const bool result =3D with_lock(m, []() -> bool
>>>> {
>>>> // ...
>>>> return true;
>>>> });
>>>>=20
>>>>=20
>>> I like the with_ proposal. I would like we compare to an alternative us=
ing lock factories.
>>>=20
>>> std::mutex m;
>>> // ...
>>> bool result;
>>> {
>>> auto lk =3D make_lock_guard(m) :
>>> // ...
>>> result =3D true
>>> }
>>>=20
>>> or using another lock
>>>=20
>>> {
>>> auto lk =3D make_unique_lock(m) :
>>> // ...
>>> }
>>>=20
>>> or locking multiple locks at once (See my proposal for make_unique_lock=
s in another post).
>>>=20
>>> {
>>> auto lk =3D make_unique_locks(m1, m2, m3);
>>> // ...
>>> }
>>>=20
>>> Note that lock_guard needs to be modified so that it can be created fro=
m the result of make_lock_guard.
>>=20
>> Just write it like this:
>>=20
>> auto&& lk =3D make_lock_guard(m);
>>=20
>> and you won't need to modify lock_guard.
>>=20
>>=20
> Thanks for the hint. I've declared make_lock_guard as
>=20
> template <typename Lockable>
> lock_guard<Lockable>&& make_lock_guard(Lockable& mtx);
>=20
> and I'm getting a warning:
> ../../../boost/thread/lock_guard.hpp:59:12: warning: returning reference =
to local temporary object [-Wreturn-stack-address]
> return lock_guard<Lockable>(mtx);
>=20
> which seems correct to me.
>=20
> Is this the correct way to declare it?
I don't see how this is going to work. I've tried it two ways:
This doesn't compile:
#include <iostream>
struct A
{
A() =3D default;
A(const A&) =3D delete;
A& operator=3D(const A&) =3D delete;
~A() {std::cout << "~A()\n";}
};
A
make_A()
{
return A();
}
int
main()
{
{
auto&& _ =3D make_A();
std::cout << "Within scope\n";
}
std::cout << "Outside scope\n";
}
test.cpp:14:12: error: call to deleted constructor of 'A'
return A();
^~~
test.cpp:6:5: note: function has been explicitly marked deleted here
A(const A&) =3D delete;
^
1 error generated.
This compiles but is not a well-formed program:
#include <iostream>
struct A
{
A() =3D default;
A(const A&) =3D delete;
A& operator=3D(const A&) =3D delete;
~A() {std::cout << "~A()\n";}
};
A&&
make_A()
{
return A();
}
int
main()
{
{
auto&& _ =3D make_A();
std::cout << "Within scope\n";
}
std::cout << "Outside scope\n";
}
test.cpp:14:12: warning: returning reference to local temporary object [-Wr=
eturn-stack-address]
return A();
^~~
1 warning generated.
~A()
Within scope
Outside scope
unique_lock on the other hand, is well-behaved:
#include <iostream>
struct A
{
A() =3D default;
A(const A&) =3D delete;
A& operator=3D(const A&) =3D delete;
A(A&&) =3D default;
A& operator=3D(A&&) =3D default;
~A() {std::cout << "~A()\n";}
};
A
make_A()
{
return A();
}
int
main()
{
{
auto&& _ =3D make_A(); // or auto _ =3D ...
std::cout << "Within scope\n";
}
std::cout << "Outside scope\n";
}
Within scope
~A()
Outside scope
whether you catch it by auto&& or auto. auto is simpler syntactically.
Howard
--=20
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 20 Nov 2012 19:03:24 -0800
Raw View
On Tue, Nov 20, 2012 at 4:47 PM, Howard Hinnant
<howard.hinnant@gmail.com> wrote:
>
> On Nov 20, 2012, at 6:02 PM, "Vicente J. Botet Escriba" <vicente.botet@wa=
nadoo.fr> wrote:
>
>> Le 20/11/12 22:34, Alberto Ganesh Barbati a =E9crit :
>>>
>>> Il giorno 20/nov/2012, alle ore 20:12, Vicente J. Botet Escriba <vicent=
e.botet@wanadoo.fr> ha scritto:
>>>
>>>> Le 15/11/12 00:24, korcan.hussein@googlemail.com a =E9crit :
>>>>> You may also want to return a result from a "with" function, e.g:
>>>>>
>>>>> #include <mutex>
>>>>>
>>>>> template <typename Lockable, typename Function>
>>>>> inline auto with_lock(Lockable &lockable, Function fn) -> decltype(fn=
())
>>>>> {
>>>>> std::lock_guard<Lockable> local_lock(lockable);
>>>>> return fn();
>>>>> }
>>>>>
>>>>> //...
>>>>> std::mutex m;
>>>>> const bool result =3D with_lock(m, []() -> bool
>>>>> {
>>>>> // ...
>>>>> return true;
>>>>> });
>>>>>
>>>>>
>>>> I like the with_ proposal. I would like we compare to an alternative u=
sing lock factories.
>>>>
>>>> std::mutex m;
>>>> // ...
>>>> bool result;
>>>> {
>>>> auto lk =3D make_lock_guard(m) :
>>>> // ...
>>>> result =3D true
>>>> }
>>>>
>>>> or using another lock
>>>>
>>>> {
>>>> auto lk =3D make_unique_lock(m) :
>>>> // ...
>>>> }
>>>>
>>>> or locking multiple locks at once (See my proposal for make_unique_loc=
ks in another post).
>>>>
>>>> {
>>>> auto lk =3D make_unique_locks(m1, m2, m3);
>>>> // ...
>>>> }
>>>>
>>>> Note that lock_guard needs to be modified so that it can be created fr=
om the result of make_lock_guard.
>>>
>>> Just write it like this:
>>>
>>> auto&& lk =3D make_lock_guard(m);
>>>
>>> and you won't need to modify lock_guard.
>>>
>>>
>> Thanks for the hint. I've declared make_lock_guard as
>>
>> template <typename Lockable>
>> lock_guard<Lockable>&& make_lock_guard(Lockable& mtx);
>>
>> and I'm getting a warning:
>> ../../../boost/thread/lock_guard.hpp:59:12: warning: returning reference=
to local temporary object [-Wreturn-stack-address]
>> return lock_guard<Lockable>(mtx);
>>
>> which seems correct to me.
>>
>> Is this the correct way to declare it?
>
> I don't see how this is going to work. I've tried it two ways:
>
> This doesn't compile:
>
> #include <iostream>
>
> struct A
> {
> A() =3D default;
> A(const A&) =3D delete;
> A& operator=3D(const A&) =3D delete;
> ~A() {std::cout << "~A()\n";}
> };
>
> A
> make_A()
> {
> return A();
Here's the trick:
return {};
> }
>
> int
> main()
> {
> {
> auto&& _ =3D make_A();
> std::cout << "Within scope\n";
> }
> std::cout << "Outside scope\n";
> }
Then this works:
$ ./a.out
Within scope
~A()
Outside scope
--=20
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Tue, 20 Nov 2012 22:49:15 -0500
Raw View
On Nov 20, 2012, at 10:03 PM, Richard Smith <richard@metafoo.co.uk> wrote:
> On Tue, Nov 20, 2012 at 4:47 PM, Howard Hinnant
> <howard.hinnant@gmail.com> wrote:
>>=20
>> On Nov 20, 2012, at 6:02 PM, "Vicente J. Botet Escriba" <vicente.botet@w=
anadoo.fr> wrote:
>>=20
>>> Le 20/11/12 22:34, Alberto Ganesh Barbati a =E9crit :
>>>>=20
>>>> Il giorno 20/nov/2012, alle ore 20:12, Vicente J. Botet Escriba <vicen=
te.botet@wanadoo.fr> ha scritto:
>>>>=20
>>>>> Le 15/11/12 00:24, korcan.hussein@googlemail.com a =E9crit :
>>>>>> You may also want to return a result from a "with" function, e.g:
>>>>>>=20
>>>>>> #include <mutex>
>>>>>>=20
>>>>>> template <typename Lockable, typename Function>
>>>>>> inline auto with_lock(Lockable &lockable, Function fn) -> decltype(f=
n())
>>>>>> {
>>>>>> std::lock_guard<Lockable> local_lock(lockable);
>>>>>> return fn();
>>>>>> }
>>>>>>=20
>>>>>> //...
>>>>>> std::mutex m;
>>>>>> const bool result =3D with_lock(m, []() -> bool
>>>>>> {
>>>>>> // ...
>>>>>> return true;
>>>>>> });
>>>>>>=20
>>>>>>=20
>>>>> I like the with_ proposal. I would like we compare to an alternative =
using lock factories.
>>>>>=20
>>>>> std::mutex m;
>>>>> // ...
>>>>> bool result;
>>>>> {
>>>>> auto lk =3D make_lock_guard(m) :
>>>>> // ...
>>>>> result =3D true
>>>>> }
>>>>>=20
>>>>> or using another lock
>>>>>=20
>>>>> {
>>>>> auto lk =3D make_unique_lock(m) :
>>>>> // ...
>>>>> }
>>>>>=20
>>>>> or locking multiple locks at once (See my proposal for make_unique_lo=
cks in another post).
>>>>>=20
>>>>> {
>>>>> auto lk =3D make_unique_locks(m1, m2, m3);
>>>>> // ...
>>>>> }
>>>>>=20
>>>>> Note that lock_guard needs to be modified so that it can be created f=
rom the result of make_lock_guard.
>>>>=20
>>>> Just write it like this:
>>>>=20
>>>> auto&& lk =3D make_lock_guard(m);
>>>>=20
>>>> and you won't need to modify lock_guard.
>>>>=20
>>>>=20
>>> Thanks for the hint. I've declared make_lock_guard as
>>>=20
>>> template <typename Lockable>
>>> lock_guard<Lockable>&& make_lock_guard(Lockable& mtx);
>>>=20
>>> and I'm getting a warning:
>>> ../../../boost/thread/lock_guard.hpp:59:12: warning: returning referenc=
e to local temporary object [-Wreturn-stack-address]
>>> return lock_guard<Lockable>(mtx);
>>>=20
>>> which seems correct to me.
>>>=20
>>> Is this the correct way to declare it?
>>=20
>> I don't see how this is going to work. I've tried it two ways:
>>=20
>> This doesn't compile:
>>=20
>> #include <iostream>
>>=20
>> struct A
>> {
>> A() =3D default;
>> A(const A&) =3D delete;
>> A& operator=3D(const A&) =3D delete;
>> ~A() {std::cout << "~A()\n";}
>> };
>>=20
>> A
>> make_A()
>> {
>> return A();
>=20
> Here's the trick:
>=20
> return {};
>=20
>> }
>>=20
>> int
>> main()
>> {
>> {
>> auto&& _ =3D make_A();
>> std::cout << "Within scope\n";
>> }
>> std::cout << "Outside scope\n";
>> }
>=20
> Then this works:
>=20
> $ ./a.out
> Within scope
> ~A()
> Outside scope
I see, thanks!
So then we would need to change the lock_guard(mutex_type&) constructor to =
implicit. This could be an acceptable change.
Howard
--=20
.
Author: Alberto Ganesh Barbati <albertobarbati@gmail.com>
Date: Wed, 21 Nov 2012 22:44:02 +0100
Raw View
Il giorno 20/nov/2012, alle ore 23:15, Jeffrey Yasskin <jyasskin@googlers.com> ha scritto:
> I'd also support a proposal to make something like:
> auto __ = make_unique_lock(m1);
> auto __ = make_unique_lock(m2);
> work. (Note that I've used the same variable name twice there. "__"
> would denote an explicitly unused variable so that its name can be
> re-used. "_" would be better, but it's not currently reserved. This
> also means we don't need the 'const' since it's impossible to refer to
> the variable later.)
I'm actually thinking about that. I'd go even a bit further, I'd like the following:
auto = expr;
to have the same effect of:
const auto&& __unspecified = expr;
where expr is any expression and __unspecified is some compiler-generated identifier guaranteed to be unique in the scope.
The use of "const auto&&" (as opposed to a simple "auto") allows expr to evaluate to a non-copiable rvalue and/or to potentially avoid an unnecessary move/copy.
Given that it's a mere syntactic shortcut for an already existing feature, it should be easily implementable.
How does it sound?
Ganesh
--
.
Author: Ben Craig <ben.craig@gmail.com>
Date: Wed, 21 Nov 2012 14:51:50 -0800 (PST)
Raw View
------=_Part_943_3376448.1353538311419
Content-Type: text/plain; charset=ISO-8859-1
My current preference is for a library based proposal, but it isn't a
strong preference. I like the ease of implementation and explanation, and
I like that it treats locking in a similar way as STL algorithms. I think
that if someone sees lambdas used in this use case, they will be much more
likely to use lambdas for things like comparator functions.
That being said, the make_unique_lock approach solves the problems I
identified, and it doesn't have issues with early returns. My main two
objections are that this is a core language change instead of a library
change, and that the syntax is unusual. Either of "auto =
make_unique_lock(m);" or "const auto &&lock = make_unique_lock(m);" would
likely get questions from other developers. If I were a voting member of
the standards committee (which I'm not), I wouldn't vote down this proposal.
New C++ developers often need education about RAII objects in general, but
with the current syntax, that education can be applied in lots of areas.
This new syntax doesn't look to be as broadly applicable as RAII. I
currently know of two broad use cases with the unused temporary problem,
locking, and tracing / logging. Are these issues severe enough to
introduce a new syntax that would only really be used in those areas?
--
------=_Part_943_3376448.1353538311419
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
My current preference is for a library based proposal, but it isn't a stron=
g preference. I like the ease of implementation and explanation, and =
I like that it treats locking in a similar way as STL algorithms. I t=
hink that if someone sees lambdas used in this use case, they will be much =
more likely to use lambdas for things like comparator functions.<br><br>Tha=
t being said, the make_unique_lock approach solves the problems I identifie=
d, and it doesn't have issues with early returns. My main two objecti=
ons are that this is a core language change instead of a library change, an=
d that the syntax is unusual. Either of "auto =3D make_unique_lock(m)=
;" or "const auto &&lock =3D make_unique_lock(m);" would likely get=
questions from other developers. If I were a voting member of the st=
andards committee (which I'm not), I wouldn't vote down this proposal.<br><=
br>New C++ developers often need education about RAII objects in general,=
=20
but with the current syntax, that education can be applied in lots of=20
areas. This new syntax doesn't look to be as broadly applicable as RA=
II. I currently know of two broad use cases with the unused temporary=
problem, locking, and tracing / logging. Are these issues severe eno=
ugh to introduce a new syntax that would only really be used in those areas=
?<br>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_943_3376448.1353538311419--
.
Author: Alberto Ganesh Barbati <albertobarbati@gmail.com>
Date: Thu, 22 Nov 2012 00:34:22 +0100
Raw View
Il giorno 21/nov/2012, alle ore 23:51, Ben Craig <ben.craig@gmail.com> ha s=
critto:
> My current preference is for a library based proposal, but it isn't a str=
ong preference. I like the ease of implementation and explanation, and I l=
ike that it treats locking in a similar way as STL algorithms. I think tha=
t if someone sees lambdas used in this use case, they will be much more lik=
ely to use lambdas for things like comparator functions.
Lambda just for comparators? That's silly. Important frameworks in C++ and =
other languages are already using lambdas (or their equivalent) in interfac=
es similar to one described in the OP. For example several iOS frameworks u=
se these kind of idioms and I see a definite trend in this direction.
> That being said, the make_unique_lock approach solves the problems I iden=
tified, and it doesn't have issues with early returns. My main two objecti=
ons are that this is a core language change instead of a library change, an=
d that the syntax is unusual. Either of "auto =3D make_unique_lock(m);" or=
"const auto &&lock =3D make_unique_lock(m);" would likely get questions fr=
om other developers. If I were a voting member of the standards committee =
(which I'm not), I wouldn't vote down this proposal.
>=20
> New C++ developers often need education about RAII objects in general, bu=
t with the current syntax, that education can be applied in lots of areas. =
This new syntax doesn't look to be as broadly applicable as RAII.
This syntax IS RAII. A specific form of it, I agree, where you don't care a=
bout the name of the variable, but still RAII. In the cases where it's appl=
icable, it makes the code a bit more readable. Compare this:
std::unique_lock<std::mutex> l(m);
with:
auto =3D make_unique_lock(m);
Notice that the "auto =3D" version is also more generic, as the type of m i=
s automatically deduced. (BTW, I didn't forget the std:: prefix... it's not=
necessary because of ADL.)
> I currently know of two broad use cases with the unused temporary probl=
em, locking, and tracing / logging. Are these issues severe enough to intr=
oduce a new syntax that would only really be used in those areas?
State savers and iostream sentries are other use cases.
Ganesh
--=20
.
Author: Ben Craig <ben.craig@gmail.com>
Date: Wed, 21 Nov 2012 16:43:43 -0800 (PST)
Raw View
------=_Part_1060_13194002.1353545023700
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, November 21, 2012 5:34:31 PM UTC-6, Alberto Ganesh Barbati
wrote:
>
>
> Il giorno 21/nov/2012, alle ore 23:51, Ben Craig <ben....@gmail.com<javascript:>>
> ha scritto:
>
> > they will be much more likely to use lambdas for things like comparator
>> functions.
>>
>> Lambda just for comparators? That's silly. Important frameworks in C++
>> and other languages are already using lambdas (or their equivalent) in
>> interfaces similar to one described in the OP. For example several iOS
>> frameworks use these kind of idioms and I see a definite trend in this
>> direction.
>>
> I agree. Also, I made the original post :) . I specifically called out
comparator functions because, in the code that I deal with, comparators are
the main C++03 reason to write function objects. I see comparators and
predicates for algorithms like find_if to be a way to ease other developers
into lambdas.
This syntax IS RAII. A specific form of it, I agree, where you don't care
> about the name of the variable, but still RAII.
Yes, it is RAII. It doesn't look as much like traditional RAII as the
current C++11 unique_lock option. That doesn't mean it's a deal breaker,
just something to keep in mind.
> I currently know of two broad use cases with the unused temporary
> problem, locking, and tracing / logging. Are these issues severe enough to
> introduce a new syntax that would only really be used in those areas?
>
> State savers and iostream sentries are other use cases.
>
Ah, yes. I've even written a state saver or two. I'm not 100% sure that
iostream sentries qualify though, as they have an operator bool(), and
their destructors don't do anything (at least according to this<http://www.cplusplus.com/reference/iostream/istream/sentry/>,
haven't checked the standard).
--
------=_Part_1060_13194002.1353545023700
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Wednesday, November 21, 2012 5:34:31 PM UTC-6, Alberto Ganesh Ba=
rbati wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Il giorno 21/nov/2012, alle ore 23:51, Ben Craig <<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"MtAqxLgXOiUJ">ben....@gmai=
l.com</a>> ha scritto:
<br>
<br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid =
rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">> they wil=
l be much more likely to use lambdas for things like comparator functions.
<br><br>Lambda just for comparators? That's silly. Important frameworks in =
C++ and other languages are already using lambdas (or their equivalent) in =
interfaces similar to one described in the OP. For example several iOS fram=
eworks use these kind of idioms and I see a definite trend in this directio=
n.
<br></blockquote></blockquote><div>I agree. Also, I made the original=
post :) . I specifically called out comparator functions because, in=
the code that I deal with, comparators are the main C++03 reason to write =
function objects. I see comparators and predicates for algorithms lik=
e find_if to be a way to ease other developers into lambdas.<br><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">This syntax IS RAII. A specific=
form of it, I agree, where you don't care about the name of the variable, =
but still RAII. </blockquote><div>Yes, it is RAII. It doesn't lo=
ok as much like traditional RAII as the current C++11 unique_lock option.&n=
bsp; That doesn't mean it's a deal breaker, just something to keep in mind.=
<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> I c=
urrently know of two broad use cases with the unused temporary problem, loc=
king, and tracing / logging. Are these issues severe enough to introd=
uce a new syntax that would only really be used in those areas?
<br>
<br>State savers and iostream sentries are other use cases.
<br></blockquote><div> Ah, yes. I've even written a state saver =
or two. I'm not 100% sure that iostream sentries qualify though, as t=
hey have an operator bool(), and their destructors don't do anything (at le=
ast according to <a href=3D"http://www.cplusplus.com/reference/iostream/ist=
ream/sentry/">this</a>, haven't checked the standard).<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_1060_13194002.1353545023700--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 22 Nov 2012 08:50:16 +0100
Raw View
Le 22/11/12 00:34, Alberto Ganesh Barbati a =E9crit :
>> I currently know of two broad use cases with the unused temporary pro=
blem, locking, and tracing / logging. Are these issues severe enough to in=
troduce a new syntax that would only really be used in those areas?
> State savers and iostream sentries are other use cases.
>
Just to add some of the discussed recently scope exit
auto =3D scope(exit);
auto. =3D scope(success) ;
auto =3D scope(failure);
and transactions
auto =3D transaction(...);
The real and practical examples are quite numerous.
Vicente
--=20
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Thu, 22 Nov 2012 10:37:46 +0100
Raw View
> auto = scope(exit);
> auto. = scope(success) ;
> auto = scope(failure);
>
> and transactions
>
> auto = transaction(...);
>
> The real and practical examples are quite numerous.
>
> Vicente
>
I haven't quite decided how useful i think this would be.. however, if
we want something like this
I wonder if we want to go bit more generic.. let example tell it all..
auto ? = make_whatever();
std::unique_ptr<int> ?( new int );
struct A {
int ? = 1;
};
where ? is marker for unique name.
Then again, maybe it is too confusing and the simple solution is preferred.
Mikael
--
.
Author: Alberto Ganesh Barbati <albertobarbati@gmail.com>
Date: Tue, 20 Nov 2012 13:06:25 +0100
Raw View
Il giorno 20/nov/2012, alle ore 02:24, stackmachine@hotmail.com ha scritto:
> Why not introduce something similar to Java's synchronized keyword instead?
> synchronized(mutex)
> {
> // ...
> }
>
> // equivalent to:
> {
> std::lock_guard<decltype(mutex)> __lock;
shouldn't that be
std::lock_guard<decltype(mutex)> __lock(mutex);
?
> // ...
> }
>
You have to understand that we can't afford to introduce core features so specialized, which tie with the library so much, all for a little notation gain.
If you want to suggest a core feature, you have to aim at something more general and less coupled with the library.
For example, if you declare the following:
template <class Mutex>
std::lock_guard<Mutex> synchronize(Mutex& m)
{
return std::lock_guard<Mutex>(m);
}
then you could write:
{
auto&& lock = synchronize(mutex);
// ...
}
which would effectively have the same semantic that you propose (by binding the temporary lock_guard to a reference, you effectively extend its lifetime up to end of the scope).
Now, and this could be the base for a nice proposal, if we just could have a syntax to get rid of the "auto&& lock =" while keeping the same semantic... ;-)
Ganesh
--
.
Author: Ben Craig <ben.craig@gmail.com>
Date: Tue, 27 Nov 2012 19:08:39 -0800 (PST)
Raw View
------=_Part_454_7295830.1354072119260
Content-Type: multipart/alternative;
boundary="----=_Part_455_13133469.1354072119260"
------=_Part_455_13133469.1354072119260
Content-Type: text/plain; charset=ISO-8859-1
I have a proposal for the library based approach, very similar to my
initial post. I have attached the html version, and you can view an online
version here:
https://docs.google.com/document/d/1hSMTw-N2PxapY0SykgfGAPY41HnTMNs7CHKEcptFdzA/edit
I have likely misrepresented the core-language alternative, so any feedback
on that would be appreciated. The SFINAE for the unique_lock version is a
bit rough, so if there are suggestions for that, then that would also be
welcome.
--
------=_Part_455_13133469.1354072119260
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br>I have a proposal for the library based approach, very similar to my in=
itial post. I have attached the html version, and you can view an onl=
ine version here:<br>https://docs.google.com/document/d/1hSMTw-N2PxapY0Sykg=
fGAPY41HnTMNs7CHKEcptFdzA/edit<br><br>I have likely misrepresented the core=
-language alternative, so any feedback on that would be appreciated. =
The SFINAE for the unique_lock version is a bit rough, so if there are sugg=
estions for that, then that would also be welcome.<br>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_455_13133469.1354072119260--
------=_Part_454_7295830.1354072119260
Content-Type: text/html; charset=US-ASCII; name=with_lock_proposal.html
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=with_lock_proposal.html
X-Attachment-Id: 034e1d49-fd7c-4d8d-8739-177a856e3637
<h1>with_lock, a function based way of scoping locks</h1>
Date: 2012-11-27<br/>
Project: Programming Language C++, Library Working Group<br/>
Reply-to: Ben Craig <ben dot craig at gmail dot com><br/>
<h2>The problem</h2>
A long-time source of RAII locking bugs comes from code similar to the following:<br/>
<pre>std::lock_guard<std::mutex>(m);</pre>
Here, the developer intended to lock a mutex, execute some protected code, then unlock the mutex. Instead, the developer locked, and immediately unlocked the mutex, because they failed to name the object.<br/>
There is also an aesthetic issue here. The developer needs to mention the mutex type, when, ideally, it would be deduced.
<h2>The solution</h2>
I propose adding a new function (with_lock) with two overloads to C++. Both with_lock overloads will take a Mutex as the first parameter, and a callable object as the second parameter. The more basic overload will require the callable object take no parameters, and the advanced overload will require the callable object take a std::unique_lock parameter by reference. The advanced overload is to enable fine grained locking control and condition_variables. Here are some example uses:<br/>
<pre>std::mutex m;
int q = std::with_lock(m, []{
++global_count;
return global_count;
});
std::condition_variable cond_var;
bool notified = false;
std::with_lock(m, [&](std::unique_lock<std::mutex> &l){
while (!notified)
cond_var.wait(l);
});</pre>
Here is a reference implementation of the two with_lock overloads:<br/>
<pre>template <typename Mutex, typename Func>
auto with_lock(Mutex &m, Func f) -> decltype(f())
{
lock_guard<Mutex> guard(m);
return f();
}
namespace detail {
template <typename T>
unique_lock<T> &get_unique_lock_ref();
}
template <typename Mutex, typename Func>
auto with_lock(Mutex &m, Func f) -> decltype(f(detail::get_unique_lock_ref<Mutex>()))
{
unique_lock<Mutex> guard(m);
return f(guard);
}</pre>
<h2>Known shortcomings</h2>
If a naive developer were to replace all their existing RAII locking code with "with_lock" functions and lambdas, they would likely introduce bugs in any code that had an early return statement. The early return will exit the lambda, but will not exit the surrounding function as it had before.<br/>
The unique_lock overload of with_lock requires the client code to name the unique_lock and mutex types. If n3418 (Generic Lambda Expressions) is added to the standard, then this will no longer be a concern.
<h2>Proposed change to the standard</h2>
Add the following to 30.4.3 Generic locking algorithms:<br/>
<pre>template <typename Mutex, typename Func>
auto with_lock(Mutex &, Func f) -> decltype(f());
6 Requires: The supplied Mutex type shall meet the BasicLockable requirements (30.2.5.2). The supplied object f shall be a callable object that takes no parameters. The object f is permitted to return any value.
7 Effects: Locks the supplied Mutex object, then calls the supplied object f(), then unlocks the Mutex object.
8 Returns: The result of calling f.
namespace detail {
template <typename T>
unique_lock<T> &get_unique_lock_ref();
}
template <typename Mutex, typename Func>
auto with_lock(Mutex &, Func f) -> decltype(f(detail::get_unique_lock_ref<Mutex>()))
9 Requires: The supplied Mutex type shall meet the BasicLockable requirements (30.2.5.2). The supplied object f shall be a callable object that takes a unique_lock<Mutex> parameter by reference. The object f is permitted to return any value.
10 Effects: Constructs and locks a unique_lock, then calls the supplied object f with the unique_lock as a parameter, then unlocks the unique_lock.
11 Returns: The result of calling f.</pre>
<h2>Discarded alternatives</h2>
<h3>New "synchronized" keyword</h3>
Java and .NET languages have keywords to lock objects, and those keywords introduce scoping. While this may reduce the amount of syntactic noise, it doesn't reduce the noise by much, and it likely breaks existing code because of the new keyword. Java and .NET likely added their keywords due to the verbosity of scoped resource handling, a shortcoming that C++ does not have.
<h3>Unnamed variables and make_lock</h3>
A core language change could make something like the following compile:<br/>
<pre>std::mutex m;
auto = std::make_lock(m);</pre>
This addresses both the aesthetic issue of repeating mutex type declarations, and makes it more obvious when scope problems will be involved. The extensions to "auto" would be useful in situations other than locking. However, it does require a core language change to how auto works, and the author lacks the time to fully elaborate the consequences of that change.
<h2>Acknowledgements</h2>
Early ideas for these functions were discussed on isocpp.org's Future Proposals forum. Those discussions can be found <a href="https://groups.google.com/a/isocpp.org/d/topic/std-proposals/xxIpWdVPy2k/discussion">here</a>.
------=_Part_454_7295830.1354072119260--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Wed, 28 Nov 2012 08:36:07 +0100
Raw View
--bcaec517a990366dbd04cf8938b6
Content-Type: text/plain; charset=ISO-8859-1
2012/11/28 Ben Craig <ben.craig@gmail.com>
>
> I have a proposal for the library based approach, very similar to my
> initial post. I have attached the html version, and you can view an online
> version here:
>
> https://docs.google.com/document/d/1hSMTw-N2PxapY0SykgfGAPY41HnTMNs7CHKEcptFdzA/edit
>
>
In regard to the suggested library P/R ("proposed resolution"): The wording
is not acceptable, because the part
namespace detail {
template <typename T>
unique_lock<T> &get_unique_lock_ref();
}
looks to me as if it would not belong to the spec but to some prototype
implementation.
What you say about
template <typename Mutex, typename Func>
auto with_lock(Mutex &, Func f) ->
decltype(f(detail::get_unique_lock_ref<Mutex>()))
doesn't require detail::get_unique_lock_ref, because you could rewrite that
as
template <typename Mutex, typename Func>
auto with_lock(Mutex &, Func f) -> decltype(f(declval<unique_lock<Mutex>&
>()))
where declval is already part of the library spec.
Further on the part
"The object f is permitted to return any value."
should be removed, because it has no additional value.
I haven't read much of the remaining proposal.
- Daniel
--
--bcaec517a990366dbd04cf8938b6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote">2012/11/28 Ben Craig <span dir=3D"ltr"><<a hr=
ef=3D"mailto:ben.craig@gmail.com" target=3D"_blank">ben.craig@gmail.com</a>=
></span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
<br>I have a proposal for the library based approach, very similar to my in=
itial post.=A0 I have attached the html version, and you can view an online=
version here:<br><a href=3D"https://docs.google.com/document/d/1hSMTw-N2Px=
apY0SykgfGAPY41HnTMNs7CHKEcptFdzA/edit" target=3D"_blank">https://docs.goog=
le.com/document/d/1hSMTw-N2PxapY0SykgfGAPY41HnTMNs7CHKEcptFdzA/edit</a><br>
<br></blockquote><div><br></div></div>In regard to the suggested library P/=
R ("proposed resolution"): The wording is not acceptable, because=
the part<br><br><span style=3D"font-size:15px;font-family:Arial;color:#000=
000;background-color:transparent;font-weight:normal;font-style:normal;font-=
variant:normal;text-decoration:none;vertical-align:baseline" id=3D"internal=
-source-marker_0.9802612534065498">namespace detail {<br class=3D"kix-line-=
break">
=A0template <typename T><br class=3D"kix-line-break"> =A0unique_lock=
<T> &get_unique_lock_ref();<br class=3D"kix-line-break">}<br clas=
s=3D"kix-line-break"></span><br>looks to me as if it would not belong to th=
e spec but to some prototype implementation.<br>
<br>What you say about<br><br><span style=3D"font-size:15px;font-family:Ari=
al;color:#000000;background-color:transparent;font-weight:normal;font-style=
:normal;font-variant:normal;text-decoration:none;vertical-align:baseline" i=
d=3D"internal-source-marker_0.9802612534065498">template <typename Mutex=
, typename Func><br class=3D"kix-line-break">
=A0auto with_lock(Mutex &, Func f) -> decltype(f(detail::get_unique=
_lock_ref<Mutex>()))<br class=3D"kix-line-break"></span><br>doesn'=
;t require <span style=3D"font-size:15px;font-family:Arial;color:#000000;ba=
ckground-color:transparent;font-weight:normal;font-style:normal;font-varian=
t:normal;text-decoration:none;vertical-align:baseline" id=3D"internal-sourc=
e-marker_0.9802612534065498">detail::get_unique_lock_ref, because you could=
rewrite that as<br>
<br></span><span style=3D"font-size:15px;font-family:Arial;color:#000000;ba=
ckground-color:transparent;font-weight:normal;font-style:normal;font-varian=
t:normal;text-decoration:none;vertical-align:baseline" id=3D"internal-sourc=
e-marker_0.9802612534065498">template <typename Mutex, typename Func>=
<br class=3D"kix-line-break">
=A0auto with_lock(Mutex &, Func f) -> decltype(f(declval<</span>=
<span style=3D"font-size:15px;font-family:Arial;color:#000000;background-co=
lor:transparent;font-weight:normal;font-style:normal;font-variant:normal;te=
xt-decoration:none;vertical-align:baseline" id=3D"internal-source-marker_0.=
9802612534065498"><span style=3D"font-size:15px;font-family:Arial;color:#00=
0000;background-color:transparent;font-weight:normal;font-style:normal;font=
-variant:normal;text-decoration:none;vertical-align:baseline" id=3D"interna=
l-source-marker_0.9802612534065498">unique_lock<Mutex>&</span>>=
;()))<br class=3D"kix-line-break">
<br>where declval is already part of the library spec.<br><br>Further on th=
e part<br><br>"</span><span style=3D"font-size:15px;font-family:Arial;=
color:#000000;background-color:transparent;font-weight:normal;font-style:no=
rmal;font-variant:normal;text-decoration:none;vertical-align:baseline" id=
=3D"internal-source-marker_0.9802612534065498"><span style=3D"font-size:15p=
x;font-family:Arial;color:#000000;background-color:transparent;font-weight:=
normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-=
align:baseline" id=3D"internal-source-marker_0.9802612534065498">The object=
f is permitted to return any value."<br class=3D"kix-line-break">
</span><br>should be removed, because it has no additional value.<br><br>I =
haven't read much of the remaining proposal.<br><br>- Daniel<br><br><br=
></span>
<p></p>
-- <br />
<br />
<br />
<br />
--bcaec517a990366dbd04cf8938b6--
.
Author: stackmachine@hotmail.com
Date: Wed, 28 Nov 2012 00:09:13 -0800 (PST)
Raw View
------=_Part_692_26817216.1354090154052
Content-Type: text/plain; charset=ISO-8859-1
You should take your Func-Object by RValue Reference to prevent copying.
Your reason why synchronized was discarded is inaccurate.
I'm still against your proposal, Folly gets it right:
https://github.com/facebook/folly/blob/master/folly/Synchronized.h
--
------=_Part_692_26817216.1354090154052
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
You should take your Func-Object by RValue Reference to prevent copying. Yo=
ur reason why synchronized was discarded is inaccurate.<br>I'm still agains=
t your proposal, Folly gets it right: <a href=3D"https://github.com/faceboo=
k/folly/blob/master/folly/Synchronized.h">https://github.com/facebook/folly=
/blob/master/folly/Synchronized.h</a><br>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_692_26817216.1354090154052--
.
Author: stackmachine@hotmail.com
Date: Wed, 28 Nov 2012 00:10:10 -0800 (PST)
Raw View
------=_Part_111_33226249.1354090210934
Content-Type: text/plain; charset=ISO-8859-1
Err, wrong link. Here you go:
https://github.com/facebook/folly/blob/master/folly/docs/Synchronized.md
--
------=_Part_111_33226249.1354090210934
Content-Type: text/html; charset=ISO-8859-1
Err, wrong link. Here you go: <a href="https://github.com/facebook/folly/blob/master/folly/docs/Synchronized.md">https://github.com/facebook/folly/blob/master/folly/docs/Synchronized.md</a><br>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_111_33226249.1354090210934--
.
Author: Ben Craig <ben.craig@gmail.com>
Date: Wed, 28 Nov 2012 08:03:30 -0600
Raw View
--20cf3011dc139c4ff804cf8ea170
Content-Type: text/plain; charset=ISO-8859-1
>
> Further on the part
>
> "The object f is permitted to return any value."
>
> should be removed, because it has no additional value.
>
I will get rid of that. I suppose the function signature with the
decltypes already imply that.
> template <typename Mutex, typename Func>
> auto with_lock(Mutex &, Func f) -> decltype(f(declval<unique_lock<Mutex>&
> >()))
>
> where declval is already part of the library spec.
doesn't require detail::get_unique_lock_ref, because you could rewrite that
as
When prototyping, I thought I tried exactly that. But I just tried it
again, and now it works. I will update the spec, as I prefer that approach.
You should take your Func-Object by RValue Reference to prevent copying.
>
The other standard library functions accept their function objects by
value. It may make sense to update them all to use rvalue / "universal"
references. Note that current conventional wisdom is to make function
objects cheap to copy.
Folly gets it right:
> https://github.com/facebook/folly/blob/master/folly/Synchronized.h
>
I was not aware of that class / macro. I will stare at that code for a
while and figure out if it makes sense to use some of their concepts. It
certainly looks interesting.
Your reason why synchronized was discarded is inaccurate.
> <https://github.com/facebook/folly/blob/master/folly/Synchronized.h>
>
Which part of the reasoning / information is inaccurate? Note that this is
specifically rejecting a synchronized keyword, and not a Folly like
Synchronized class / macro.
--
--20cf3011dc139c4ff804cf8ea170
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote"><div><blockquote style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_=
quote"><span style=3D"vertical-align:baseline;font-variant:normal;font-styl=
e:normal;font-size:15px;background-color:transparent;text-decoration:none;f=
ont-family:Arial;font-weight:normal">Further on the part</span><br>
<span style=3D"vertical-align:baseline;font-variant:normal;font-style:norma=
l;font-size:15px;background-color:transparent;text-decoration:none;font-fam=
ily:Arial;font-weight:normal"></span><br><span style=3D"vertical-align:base=
line;font-variant:normal;font-style:normal;font-size:15px;background-color:=
transparent;text-decoration:none;font-family:Arial;font-weight:normal">&quo=
t;</span><span style=3D"vertical-align:baseline;font-variant:normal;font-st=
yle:normal;font-size:15px;background-color:transparent;text-decoration:none=
;font-family:Arial;font-weight:normal"><span style=3D"vertical-align:baseli=
ne;font-variant:normal;font-style:normal;font-size:15px;background-color:tr=
ansparent;text-decoration:none;font-family:Arial;font-weight:normal">The ob=
ject f is permitted to return any value."</span></span><br>
<span style=3D"vertical-align:baseline;font-variant:normal;font-style:norma=
l;font-size:15px;background-color:transparent;text-decoration:none;font-fam=
ily:Arial;font-weight:normal"><span style=3D"vertical-align:baseline;font-v=
ariant:normal;font-style:normal;font-size:15px;background-color:transparent=
;text-decoration:none;font-family:Arial;font-weight:normal">
</span></span><br><span style=3D"vertical-align:baseline;font-variant:norma=
l;font-style:normal;font-size:15px;background-color:transparent;text-decora=
tion:none;font-family:Arial;font-weight:normal">should be removed, because =
it has no additional value.</span><br>
</blockquote>I will get rid of that.=A0 I suppose the function signature wi=
th the decltypes already imply that.<br>=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">
<span style=3D"vertical-align:baseline;font-variant:normal;font-style:norma=
l;font-size:15px;background-color:transparent;text-decoration:none;font-fam=
ily:Arial;font-weight:normal">template <typename Mutex, typename Func>=
;<br>
=A0auto with_lock(Mutex &, Func f) -> decltype(f(declval<</span>=
<span style=3D"vertical-align:baseline;font-variant:normal;font-style:norma=
l;font-size:15px;background-color:transparent;text-decoration:none;font-fam=
ily:Arial;font-weight:normal"><span style=3D"vertical-align:baseline;font-v=
ariant:normal;font-style:normal;font-size:15px;background-color:transparent=
;text-decoration:none;font-family:Arial;font-weight:normal">unique_lock<=
Mutex>&</span>>()))<br>
<br>where declval is already part of the library spec.</span></blockquote>d=
oesn't require detail::get_unique_lock_ref, because you could rewrite t=
hat as<br><br>When prototyping, I thought I tried exactly that.=A0 But I ju=
st tried it again, and now it works.=A0 I will update the spec, as I prefer=
that approach.<br>
<br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb=
(204,204,204);padding-left:1ex" class=3D"gmail_quote">You should take your =
Func-Object by RValue Reference to prevent copying. <br></blockquote><div>T=
he other standard library functions accept their function objects by value.=
=A0 It may make sense to update them all to use rvalue / "universal&qu=
ot; references.=A0 Note that current conventional wisdom is to make functio=
n objects cheap to copy.<br>
</div><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">Folly gets it r=
ight: <a href=3D"https://github.com/facebook/folly/blob/master/folly/Synchr=
onized.h" target=3D"_blank">https://github.com/facebook/folly/blob/master/f=
olly/Synchronized.h</a><br>
</blockquote>I
was not aware of that class / macro.=A0 I will stare at that code for a=20
while and figure out if it makes sense to use some of their concepts.=A0 It=
certainly looks interesting.<br><br><blockquote style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"g=
mail_quote">
Your reason why synchronized was discarded is inaccurate.<br><a href=3D"htt=
ps://github.com/facebook/folly/blob/master/folly/Synchronized.h" target=3D"=
_blank"></a><div class=3D"yj6qo ajU"><div id=3D":i2" class=3D"ajR" tabindex=
=3D"0"><img class=3D"ajT" src=3D"https://mail.google.com/mail/images/cleard=
ot.gif"></div>
</div></blockquote>Which part of the reasoning / information is inaccurate?=
=A0 Note that this is specifically rejecting a synchronized keyword, and no=
t a Folly like Synchronized class / macro.<br><br><br></div>
<p></p>
-- <br />
<br />
<br />
<br />
--20cf3011dc139c4ff804cf8ea170--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 28 Nov 2012 18:51:22 +0100
Raw View
Le 28/11/12 09:09, stackmachine@hotmail.com a =E9crit :
> Folly gets it right:=20
> https://github.com/facebook/folly/blob/master/folly/Synchronized.h
>
How? Are you suggesting to define a macro?
--Vicente
--=20
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 28 Nov 2012 19:32:38 +0100
Raw View
This is a multi-part message in MIME format.
--------------020907040801070604080205
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 28/11/12 08:36, Daniel Kr=FCgler a =E9crit :
> 2012/11/28 Ben Craig <ben.craig@gmail.com <mailto:ben.craig@gmail.com>>
>
>
> I have a proposal for the library based approach, very similar to
> my initial post. I have attached the html version, and you can
> view an online version here:
> https://docs.google.com/document/d/1hSMTw-N2PxapY0SykgfGAPY41HnTMNs7C=
HKEcptFdzA/edit
>
>
>
Hi,
I don't know if the motivating example is a good one to show the=20
advantages of your library.
The problem with
std::lock_guard<std::mutex>(m);
is a general RAII problem, and if it is enough important, every RAII in=20
the C++ standard should be need to be considered.
The need to use artificial scopes seems more in face with your proposal
type var;
{
std::lock_guard<std::mutex>(m);
var =3D access_to_protected_data();
}
I think the proposal should show how the we can do it without with_lock
std::mutex m;
int q;
{
std::lock_guard<std::mutex> lk(m);
++global_count;
q =3D global_count;
}
std::condition_variable cond_var;
bool notified =3D false;
{
std::unique_lock<std::mutex> lk(m);
while (!notified)
cond_var.wait(l);
}
You could move the reference implementation to a specific section.
The fact that we can not return from the protected function seems a big=20
drawback compared to the current solution
E.g. should the user continue to use lock_guard in this context?
{
std::lock_guard<std::mutex>(m);
if (cnd) return access_to_protected_data();
another_access_to_protected_data();
}
Before the unnamed variable make_lock, there is the alternative to use a=20
named one
std::mutex m;
int q;
{
auto && lk =3D std::make_lock_guard(m);
++global_count;
q =3D global_count;
}
std::condition_variable cond_var;
bool notified =3D false;
{
auto lk =3D std::make_unique_lock(m);
while (!notified)
cond_var.wait(l);
}
I have been thinking to mixing the *unnamed variable* and a *let-in=20
statement* to make it possible
std::mutex m;
int q;
auto&& ... =3D std::make_lock_guard(m) : {
++global_count;
q =3D global_count;
}
Note the use of ... for the unnamed variable and the colon ':' to=20
introduce a variable in a statement.
std::condition_variable cond_var;
bool notified =3D false;
auto lk =3D std::make_unique_lock(m) : {
while (!notified)
cond_var.wait(l);
}
I will create a new post to discuss about this language based=20
alternative, that of course has the disadvantage to need two language=20
evolutions :(
-- Vicente
--=20
--------------020907040801070604080205
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 28/11/12 08:36, Daniel Krügler a
écrit :<br>
</div>
<blockquote
cite="mid:CAGNvRgBWksWL64YtQk1XC8A4+TkKcX-XO2AphJY+H3i4JUEB4Q@mail.gmail.com"
type="cite">
<div class="gmail_quote">2012/11/28 Ben Craig <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:ben.craig@gmail.com"
target="_blank">ben.craig@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I have a proposal for the library based approach, very similar
to my initial post. I have attached the html version, and you
can view an online version here:<br>
<a moz-do-not-send="true"
href="https://docs.google.com/document/d/1hSMTw-N2PxapY0SykgfGAPY41HnTMNs7CHKEcptFdzA/edit"
target="_blank">https://docs.google.com/document/d/1hSMTw-N2PxapY0SykgfGAPY41HnTMNs7CHKEcptFdzA/edit</a><br>
<br>
</blockquote>
<div><br>
</div>
</div>
<br>
</blockquote>
Hi,<br>
<br>
I don't know if the motivating example is a good one to show the
advantages of your library.<br>
<br>
The problem with <br>
<br>
std::lock_guard<std::mutex>(m);<br>
<br>
is a general RAII problem, and if it is enough important, every RAII
in the C++ standard should be need to be considered.<br>
<br>
The need to use artificial scopes seems more in face with your
proposal<br>
<br>
type var;<br>
{<br>
std::lock_guard<std::mutex>(m);<br>
var = access_to_protected_data();<br>
}<br>
<br>
I think the proposal should show how the we can do it without
with_lock<br>
<br>
std::mutex m;<br>
<p style="margin-bottom: 0cm">int q;<br>
{ <br>
std::lock_guard<std::mutex> lk(m);<br>
++global_count;<br>
q =
global_count;<br>
}</p>
<p style="margin-bottom: 0cm">std::condition_variable cond_var;<br>
bool
notified = false;<br>
{ <br>
std::unique_lock<std::mutex> lk(m);<br>
while
(!notified)<br>
cond_var.wait(l);<br>
}</p>
<title></title>
<meta name="GENERATOR" content="OpenOffice.org 3.3 (Unix)">
<style type="text/css">
<!--
@page { margin: 2cm }
P { margin-bottom: 0.21cm }
-->
</style><br>
You could move the reference implementation to a specific section.<br>
<br>
The fact that we can not return from the protected function seems a
big drawback compared to the current solution<br>
<br>
E.g. should the user continue to use lock_guard in this context?<br>
<br>
{<br>
std::lock_guard<std::mutex>(m);<br>
if (cnd) return access_to_protected_data();<br>
another_access_to_protected_data();<br>
}<br>
<br>
<br>
Before the unnamed variable make_lock, there is the alternative to
use a named one<br>
<p style="margin-bottom: 0cm">std::mutex m;<br>
int q;<br>
{ <br>
auto && lk = std::make_lock_guard(m);<br>
++global_count;<br>
q =
global_count;<br>
}</p>
<p style="margin-bottom: 0cm">std::condition_variable cond_var;<br>
bool
notified = false;<br>
{ <br>
auto lk = std::make_unique_lock(m);<br>
while
(!notified)<br>
cond_var.wait(l);<br>
}</p>
<br>
I have been thinking to mixing the *unnamed variable* and a *let-in
statement* to make it possible<br>
<p style="margin-bottom: 0cm">std::mutex m;<br>
int q;<br>
auto&& ... = std::make_lock_guard(m) : {<br>
++global_count;<br>
q =
global_count;<br>
}<br>
</p>
<p style="margin-bottom: 0cm"> Note the use of ... for the unnamed
variable and the colon ':' to introduce a variable in a statement.<br>
<br>
</p>
std::condition_variable cond_var;<br>
<p style="margin-bottom: 0cm">bool
notified = false;<br>
auto lk = std::make_unique_lock(m) : { <br>
while
(!notified)<br>
cond_var.wait(l);<br>
}</p>
<br>
I will create a new post to discuss about this language based
alternative, that of course has the disadvantage to need two
language evolutions :(<br>
<br>
-- Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------020907040801070604080205--
.
Author: stackmachine@hotmail.com
Date: Wed, 28 Nov 2012 11:01:30 -0800 (PST)
Raw View
------=_Part_112_24780966.1354129290261
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Am Mittwoch, 28. November 2012 18:51:22 UTC+1 schrieb viboes:
> Le 28/11/12 09:09, stackm...@hotmail.com <javascript:> a =EF=BF=BDcrit :=
=20
> > Folly gets it right:=20
> > https://github.com/facebook/folly/blob/master/folly/Synchronized.h=20
> >=20
> How? Are you suggesting to define a macro?=20
>
> --Vicente=20
>
https://github.com/facebook/folly/blob/master/folly/docs/Synchronized.md
Yes, this macro would be 10 times better at least. Along with=20
UNSYNCHRONIZED, TIMED_SYNCHRONIZED, etc.
--=20
------=_Part_112_24780966.1354129290261
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Am Mittwoch, 28. November 2012 18:51:22 UTC+1 schrieb viboes:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">Le 28/11/12 09:09, <a href=3D"javascript=
:" target=3D"_blank" gdf-obfuscated-mailto=3D"YIqaitQ-EkQJ">stackm...@hotma=
il.com</a> a =EF=BF=BDcrit :
<br>> Folly gets it right:=20
<br>> <a href=3D"https://github.com/facebook/folly/blob/master/folly/Syn=
chronized.h" target=3D"_blank">https://github.com/facebook/<wbr>folly/blob/=
master/folly/<wbr>Synchronized.h</a>
<br>>
<br>How? Are you suggesting to define a macro?
<br>
<br>--Vicente
<br></blockquote><div><a href=3D"https://github.com/facebook/folly/blob/mas=
ter/folly/docs/Synchronized.md" target=3D"_blank" style=3D"cursor: pointer;=
">https://github.com/facebook/<wbr>folly/blob/master/folly/docs/<wbr>Synchr=
onized.md</a></div><div>Yes, this macro would be 10 times better at least. =
Along with UNSYNCHRONIZED, TIMED_SYNCHRONIZED, etc.</div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_112_24780966.1354129290261--
.
Author: Ben Craig <ben.craig@gmail.com>
Date: Wed, 28 Nov 2012 19:01:01 -0800 (PST)
Raw View
------=_Part_389_632841.1354158061764
Content-Type: text/plain; charset=ISO-8859-1
> I don't know if the motivating example is a good one to show the
> advantages of your library.
>
> The problem with
>
> std::lock_guard<std::mutex>(m);
>
> is a general RAII problem, and if it is enough important, every RAII in
> the C++ standard should be need to be considered.
>
It is a problem with a subset of RAII classes. It is a problem with RAII
classes with destructor side-effects, where common usage patterns don't use
the name elsewhere. lock_guard is one such class, but unique_lock isn't as
much of a problem, since typical usages of unique_lock will use the lock
again. In addition, lock_guard is particularly problematic in that the
program will appear to work, until mysterious race conditions start
hitting. To your point though, I will modify my proposal to show how to do
this correctly with a named lock.
I can mention the make_lock_guard approach. I am not a fan of that
approach because of the unusual auto && syntax. I can mention the
make_unique_lock approach. I sort of like that one, as the syntax isn't as
gross, and it does solve the specific problems mentioned. It is also
purely library based. I will probably just shorten it to "make_lock"
though.
The language alternatives look interesting, but I will leave those
proposals to you. I've gotten brave enough to propose new library
features, but I haven't gotten brave enough to propose core language
features yet.
--
------=_Part_389_632841.1354158061764
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" t=
ext=3D"#000000">
I don't know if the motivating example is a good one to show the
advantages of your library.<br>
<br>
The problem with <br>
<br>
std::lock_guard<std::mutex>(m)<wbr>;<br>
<br>
is a general RAII problem, and if it is enough important, every RAII
in the C++ standard should be need to be considered.</div></blockquote>=
<br>It is a problem with a subset of RAII classes. It is a problem wi=
th RAII classes with destructor side-effects, where common usage patterns d=
on't use the name elsewhere. lock_guard is one such class, but unique=
_lock isn't as much of a problem, since typical usages of unique_lock will =
use the lock again. In addition, lock_guard is particularly problemat=
ic in that the program will appear to work, until mysterious race condition=
s start hitting. To your point though, I will modify my proposal to s=
how how to do this correctly with a named lock.<br><br><br>I can mention th=
e make_lock_guard approach. I am not a fan of that approach because o=
f the unusual auto && syntax. I can mention the make_unique_l=
ock approach. I sort of like that one, as the syntax isn't as gross, =
and it does solve the specific problems mentioned. It is also purely =
library based. I will probably just shorten it to "make_lock" though.=
<br><br>The language alternatives look interesting, but I will leave those =
proposals to you. I've gotten brave enough to propose new library fea=
tures, but I haven't gotten brave enough to propose core language features =
yet.<br><br>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_389_632841.1354158061764--
.
Author: Ben Craig <ben.craig@gmail.com>
Date: Wed, 28 Nov 2012 19:13:21 -0800 (PST)
Raw View
------=_Part_437_29020992.1354158801259
Content-Type: text/plain; charset=ISO-8859-1
> https://github.com/facebook/folly/blob/master/folly/docs/Synchronized.md
> Yes, this macro would be 10 times better at least. Along with
> UNSYNCHRONIZED, TIMED_SYNCHRONIZED, etc.
>
A macro based implementation has similar problems to a keyword based
approach in the amount of code that it breaks. Macros don't obey
namespaces. If C++1y were to use Folly's approach, and used the same names
as Folly, then it would almost certainly break code that uses Folly. If it
uses different "good" names, it will probably break some other library. I
think the only macro names it could use that wouldn't break code (at least
according to the standard) would be names with leading underscores.
I will address Folly in the alternatives section, as it is still a very
nice facility. Some use cases, like locking a vector, are very nice.
Other use cases aren't really improved by the Folly approach though, like
locking for the duration of every member function of a class. Folly's
approach is also more invasive. Your lock and data declarations need to
change. It is harder for locks that aren't packaged with SYNCHRONIZED to
be usable by SYNCHRONIZED. You have to overload op-> in a very unusual way.
--
------=_Part_437_29020992.1354158801259
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div><a href=3D"https://gi=
thub.com/facebook/folly/blob/master/folly/docs/Synchronized.md" target=3D"_=
blank">https://github.com/facebook/<wbr>folly/blob/master/folly/docs/<wbr>S=
ynchronized.md</a></div><div>Yes, this macro would be 10 times better at le=
ast. Along with UNSYNCHRONIZED, TIMED_SYNCHRONIZED, etc.</div></blockquote>=
<div><br>A macro based implementation has similar problems to a keyword bas=
ed approach in the amount of code that it breaks. Macros don't obey n=
amespaces. If C++1y were to use Folly's approach, and used the same n=
ames as Folly, then it would almost certainly break code that uses Folly.&n=
bsp; If it uses different "good" names, it will probably break some other l=
ibrary. I think the only macro names it could use that wouldn't break=
code (at least according to the standard) would be names with leading unde=
rscores.<br><br>I will address Folly in the alternatives section, as it is =
still a very nice facility. Some use cases, like locking a vector, ar=
e very nice. Other use cases aren't really improved by the Folly appr=
oach though, like locking for the duration of every member function of a cl=
ass. Folly's approach is also more invasive. Your lock and data=
declarations need to change. It is harder for locks that aren't pack=
aged with SYNCHRONIZED to be usable by SYNCHRONIZED. You have to over=
load op-> in a very unusual way.<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_437_29020992.1354158801259--
.
Author: stackmachine@hotmail.com
Date: Wed, 28 Nov 2012 20:47:20 -0800 (PST)
Raw View
------=_Part_31_5910902.1354164440678
Content-Type: text/plain; charset=ISO-8859-1
Am Donnerstag, 29. November 2012 04:13:21 UTC+1 schrieb Ben Craig:
>
>
> https://github.com/facebook/folly/blob/master/folly/docs/Synchronized.md
>> Yes, this macro would be 10 times better at least. Along with
>> UNSYNCHRONIZED, TIMED_SYNCHRONIZED, etc.
>>
>
> A macro based implementation has similar problems to a keyword based
> approach in the amount of code that it breaks. Macros don't obey
> namespaces. If C++1y were to use Folly's approach, and used the same names
> as Folly, then it would almost certainly break code that uses Folly. If it
> uses different "good" names, it will probably break some other library. I
> think the only macro names it could use that wouldn't break code (at least
> according to the standard) would be names with leading underscores.
>
> I will address Folly in the alternatives section, as it is still a very
> nice facility. Some use cases, like locking a vector, are very nice.
> Other use cases aren't really improved by the Folly approach though, like
> locking for the duration of every member function of a class. Folly's
> approach is also more invasive. Your lock and data declarations need to
> change. It is harder for locks that aren't packaged with SYNCHRONIZED to
> be usable by SYNCHRONIZED. You have to overload op-> in a very unusual way.
>
You don't have to tell me the problems of macros, I'm well aware of that.
I'm also not saying that we need to introduce these macros. But with
current language features it's better than your solution.
To convince users of the standard library to use your facility, you have to
show use cases where it helps them write better oder simpler code. I
personally have never seen the problem you mentioned happening, plus your
facility makes my code more verbose. Why would i want to use it?
Folly's macros however help me write simpler code, by just writing
SYNCHRONIZED, instead of some lock_guard (which is much simpler to type),
plus i don't have to create an extra mutex, it's packaged together with the
object i want to lock. That is a very convenient solution I would
definitely want to use as a user.
In my opinion you have either 2 options that would work:
- Put it into the standard library, using macros
- Bake it into the core language
Any other options are too verbose and don't have enough advantages for
users.
That being said, how about this: add keywords like synchronized, and make
them only available if the header <synchronized> is included. Allow code to
use these keywords as identifiers as long as this header isn't included.
And if you want to make it a library feature: Prefix these macros by STD_
--
------=_Part_31_5910902.1354164440678
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>Am Donnerstag, 29. November 2012 04:13:21 UTC+1 schrieb Ben Craig:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><br><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div><a href=3D"https://github.com/facebook/folly/blob/master/=
folly/docs/Synchronized.md" target=3D"_blank">https://github.com/facebook/<=
wbr>folly/blob/master/folly/docs/<wbr>Synchronized.md</a></div><div>Yes, th=
is macro would be 10 times better at least. Along with UNSYNCHRONIZED, TIME=
D_SYNCHRONIZED, etc.</div></blockquote><div><br>A macro based implementatio=
n has similar problems to a keyword based approach in the amount of code th=
at it breaks. Macros don't obey namespaces. If C++1y were to us=
e Folly's approach, and used the same names as Folly, then it would almost =
certainly break code that uses Folly. If it uses different "good" nam=
es, it will probably break some other library. I think the only macro=
names it could use that wouldn't break code (at least according to the sta=
ndard) would be names with leading underscores.<br><br>I will address Folly=
in the alternatives section, as it is still a very nice facility. So=
me use cases, like locking a vector, are very nice. Other use cases a=
ren't really improved by the Folly approach though, like locking for the du=
ration of every member function of a class. Folly's approach is also =
more invasive. Your lock and data declarations need to change. =
It is harder for locks that aren't packaged with SYNCHRONIZED to be usable =
by SYNCHRONIZED. You have to overload op-> in a very unusual way.<=
br></div></blockquote><div>You don't have to tell me the problems of macros=
, I'm well aware of that. I'm also not saying that we need to introduce the=
se macros. But with current language features it's better than your solutio=
n.</div><div>To convince users of the standard library to use your facility=
, you have to show use cases where it helps them write better oder simpler =
code. I personally have never seen the problem you mentioned happening, plu=
s your facility makes my code more verbose. Why would i want to use it?</di=
v><div>Folly's macros however help me write simpler code, by just writing S=
YNCHRONIZED, instead of some lock_guard (which is much simpler to type), pl=
us i don't have to create an extra mutex, it's packaged together with the o=
bject i want to lock. That is a very convenient solution I would definitely=
want to use as a user.</div><div><br></div><div>In my opinion you have eit=
her 2 options that would work:</div><div><ul><li><span style=3D"line-height=
: normal;">Put it into the standard library, using macros</span></li><li><s=
pan style=3D"line-height: normal;">Bake it into the core language</span></l=
i></ul><div>Any other options are too verbose and don't have enough advanta=
ges for users.</div></div><div><br></div><div>That being said, how about th=
is: add keywords like synchronized, and make them only available if the hea=
der <synchronized> is included. Allow code to use these keywords as i=
dentifiers as long as this header isn't included.</div><div>And if you want=
to make it a library feature: Prefix these macros by STD_</div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_31_5910902.1354164440678--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 29 Nov 2012 12:07:08 -0500
Raw View
On Wed, Nov 28, 2012 at 10:13 PM, Ben Craig <ben.craig@gmail.com> wrote:
>
>
> I will address Folly in the alternatives section, as it is still a very nice
> facility. Some use cases, like locking a vector, are very nice. Other use
> cases aren't really improved by the Folly approach though, like locking for
> the duration of every member function of a class. Folly's approach is also
> more invasive. Your lock and data declarations need to change. It is
> harder for locks that aren't packaged with SYNCHRONIZED to be usable by
> SYNCHRONIZED. You have to overload op-> in a very unusual way.
>
I would add that (IMO) the synchronized operator-> is harmful. It
leads to misunderstandings like:
Synchronized<Container> container;
....
if (!container->empty()) {
auto item = container->front();
...
}
hey the container was synchronized, why does this crash (but only rarely)?
Maybe this is programmer error, but I think we have enough foot-guns
already. If it was my library, I'd only offer the SYNCHRONIZED macro,
not the single-function shortcuts.
Tony
--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 29 Nov 2012 23:37:47 +0100
Raw View
Le 29/11/12 18:07, Tony V E a =E9crit :
> On Wed, Nov 28, 2012 at 10:13 PM, Ben Craig <ben.craig@gmail.com> wrote:
>>
>> I will address Folly in the alternatives section, as it is still a very =
nice
>> facility. Some use cases, like locking a vector, are very nice. Other =
use
>> cases aren't really improved by the Folly approach though, like locking =
for
>> the duration of every member function of a class. Folly's approach is a=
lso
>> more invasive. Your lock and data declarations need to change. It is
>> harder for locks that aren't packaged with SYNCHRONIZED to be usable by
>> SYNCHRONIZED. You have to overload op-> in a very unusual way.
>>
> I would add that (IMO) the synchronized operator-> is harmful. It
> leads to misunderstandings like:
>
> Synchronized<Container> container;
> ...
> if (!container->empty()) {
> auto item =3D container->front();
> ...
> }
>
> hey the container was synchronized, why does this crash (but only rarely)=
?
>
> Maybe this is programmer error, but I think we have enough foot-guns
> already. If it was my library, I'd only offer the SYNCHRONIZED macro,
> not the single-function shortcuts.
>
>
Yes, there is an error here. Do you mean that the error would be more=20
visible if a synchronize function was used instead, as in
if (!container.synchronize().empty()) {
auto item =3D container.synchronize().front();
...
}
Vicente
P.S. There is an interesting article "Enforcing Correct Mutex Usage with Sy=
nchronized Values" from Anthony William here http://www.drdobbs.com/cpp/enf=
orcing-correct-mutex-usage-with-synch/225200269. Boost.Thread has in trunk =
a synchronized_value based on this paper which should be delivered on Boost=
..1.53.
--=20
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 29 Nov 2012 23:56:30 +0100
Raw View
This is a multi-part message in MIME format.
--------------060600020906040804010809
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 29/11/12 05:47, stackmachine@hotmail.com a =E9crit :
>
>
> Am Donnerstag, 29. November 2012 04:13:21 UTC+1 schrieb Ben Craig:
>
>
> https://github.com/facebook/folly/blob/master/folly/docs/Synchron=
ized.md
> <https://github.com/facebook/folly/blob/master/folly/docs/Synchro=
nized.md>
> Yes, this macro would be 10 times better at least. Along with
> UNSYNCHRONIZED, TIMED_SYNCHRONIZED, etc.
>
>
> A macro based implementation has similar problems to a keyword
> based approach in the amount of code that it breaks. Macros don't
> obey namespaces. If C++1y were to use Folly's approach, and used
> the same names as Folly, then it would almost certainly break code
> that uses Folly. If it uses different "good" names, it will
> probably break some other library. I think the only macro names
> it could use that wouldn't break code (at least according to the
> standard) would be names with leading underscores.
>
> I will address Folly in the alternatives section, as it is still a
> very nice facility. Some use cases, like locking a vector, are
> very nice. Other use cases aren't really improved by the Folly
> approach though, like locking for the duration of every member
> function of a class. Folly's approach is also more invasive.=20
> Your lock and data declarations need to change. It is harder for
> locks that aren't packaged with SYNCHRONIZED to be usable by
> SYNCHRONIZED. You have to overload op-> in a very unusual way.
>
> You don't have to tell me the problems of macros, I'm well aware of=20
> that. I'm also not saying that we need to introduce these macros. But=20
> with current language features it's better than your solution.
So you are not proposing the introduction of a new macro 'synchronized'.
> To convince users of the standard library to use your facility, you=20
> have to show use cases where it helps them write better oder simpler=20
> code. I personally have never seen the problem you mentioned=20
> happening, plus your facility makes my code more verbose. Why would i=20
> want to use it?
> Folly's macros however help me write simpler code, by just writing=20
> SYNCHRONIZED, instead of some lock_guard (which is much simpler to=20
> type), plus i don't have to create an extra mutex, it's packaged=20
> together with the object i want to lock. That is a very convenient=20
> solution I would definitely want to use as a user.
The fact of packaging a mutex with the data it protects is independent=20
from how the mutex is locked. We could suggest the addition of a=20
synchronized_value template class to the C++standard [1], but this will=20
not address the PO concern.
>
> In my opinion you have either 2 options that would work:
>
> * Put it into the standard library, using macros
>
I've not see any library proposal using macros. maybe we need a first time.
>
> * Bake it into the core language
>
Humm, I don't think we can change the core language each time the=20
language could respond better to a need. C++ is already too big and=20
needs more important features that will make it even bigger.
> Any other options are too verbose and don't have enough advantages for=20
> users.
What do you think of the alternative
{
auto lk =3D synchronize(m);
// access to protected data
}
>
> That being said, how about this: add keywords like synchronized, and=20
> make them only available if the header <synchronized> is included.=20
> Allow code to use these keywords as identifiers as long as this header=20
> isn't included.
conditional keywords? This doesn't change the fact that you are adding a=20
keyword, even if local to compilation unit.
> And if you want to make it a library feature: Prefix these macros by STD_
I would accept a macro STD_SYNCHRONIZED if there is no better option.=20
See my post on Let in statement and unamed variables which could allow=20
you to write
auto =3D synchronize(m) :
{
// access to protected data
}
without introducing any new keyword.
Vicente
[1] "Enforcing Correct Mutex Usage with Synchronized Values" from=20
Anthony William here=20
http://www.drdobbs.com/cpp/enforcing-correct-mutex-usage-with-synch/2252002=
69.=20
--=20
--------------060600020906040804010809
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 29/11/12 05:47,
<a class="moz-txt-link-abbreviated" href="mailto:stackmachine@hotmail.com">stackmachine@hotmail.com</a> a écrit :<br>
</div>
<blockquote
cite="mid:78f8cc87-6f4f-41ef-91ee-5a3029276940@isocpp.org"
type="cite"><br>
<br>
Am Donnerstag, 29. November 2012 04:13:21 UTC+1 schrieb Ben Craig:
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>
<blockquote class="gmail_quote"
style="margin:0;margin-left:0.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div><a moz-do-not-send="true"
href="https://github.com/facebook/folly/blob/master/folly/docs/Synchronized.md"
target="_blank">https://github.com/facebook/<wbr>folly/blob/master/folly/docs/<wbr>Synchronized.md</a></div>
<div>Yes, this macro would be 10 times better at least. Along
with UNSYNCHRONIZED, TIMED_SYNCHRONIZED, etc.</div>
</blockquote>
<div><br>
A macro based implementation has similar problems to a keyword
based approach in the amount of code that it breaks. Macros
don't obey namespaces. If C++1y were to use Folly's approach,
and used the same names as Folly, then it would almost
certainly break code that uses Folly. If it uses different
"good" names, it will probably break some other library. I
think the only macro names it could use that wouldn't break
code (at least according to the standard) would be names with
leading underscores.<br>
<br>
I will address Folly in the alternatives section, as it is
still a very nice facility. Some use cases, like locking a
vector, are very nice. Other use cases aren't really improved
by the Folly approach though, like locking for the duration of
every member function of a class. Folly's approach is also
more invasive. Your lock and data declarations need to
change. It is harder for locks that aren't packaged with
SYNCHRONIZED to be usable by SYNCHRONIZED. You have to
overload op-> in a very unusual way.<br>
</div>
</blockquote>
<div>You don't have to tell me the problems of macros, I'm well
aware of that. I'm also not saying that we need to introduce
these macros. But with current language features it's better
than your solution.</div>
</blockquote>
So you are not proposing the introduction of a new macro
'synchronized'.<br>
<blockquote
cite="mid:78f8cc87-6f4f-41ef-91ee-5a3029276940@isocpp.org"
type="cite">
<div>To convince users of the standard library to use your
facility, you have to show use cases where it helps them write
better oder simpler code. I personally have never seen the
problem you mentioned happening, plus your facility makes my
code more verbose. Why would i want to use it?</div>
<div>Folly's macros however help me write simpler code, by just
writing SYNCHRONIZED, instead of some lock_guard (which is much
simpler to type), plus i don't have to create an extra mutex,
it's packaged together with the object i want to lock. That is a
very convenient solution I would definitely want to use as a
user.</div>
</blockquote>
The fact of packaging a mutex with the data it protects is
independent from how the mutex is locked. We could suggest the
addition of a synchronized_value template class to the C++standard
[1], but this will not address the PO concern. <br>
<blockquote
cite="mid:78f8cc87-6f4f-41ef-91ee-5a3029276940@isocpp.org"
type="cite">
<div><br>
</div>
<div>In my opinion you have either 2 options that would work:</div>
<div>
<ul>
<li><span style="line-height: normal;">Put it into the
standard library, using macros</span></li>
</ul>
</div>
</blockquote>
I've not see any library proposal using macros. maybe we need a
first time.<br>
<blockquote
cite="mid:78f8cc87-6f4f-41ef-91ee-5a3029276940@isocpp.org"
type="cite">
<div>
<ul>
<li><span style="line-height: normal;">Bake it into the core
language</span></li>
</ul>
</div>
</blockquote>
Humm, I don't think we can change the core language each time the
language could respond better to a need. C++ is already too big and
needs more important features that will make it even bigger.<br>
<blockquote
cite="mid:78f8cc87-6f4f-41ef-91ee-5a3029276940@isocpp.org"
type="cite">
<div>
<div>Any other options are too verbose and don't have enough
advantages for users.</div>
</div>
</blockquote>
What do you think of the alternative<br>
<br>
{<br>
auto lk = synchronize(m);<br>
// access to protected data<br>
}<br>
<blockquote
cite="mid:78f8cc87-6f4f-41ef-91ee-5a3029276940@isocpp.org"
type="cite">
<div><br>
</div>
<div>That being said, how about this: add keywords like
synchronized, and make them only available if the header
<synchronized> is included. Allow code to use these
keywords as identifiers as long as this header isn't included.</div>
</blockquote>
conditional keywords? This doesn't change the fact that you are
adding a keyword, even if local to compilation unit.<br>
<blockquote
cite="mid:78f8cc87-6f4f-41ef-91ee-5a3029276940@isocpp.org"
type="cite">
<div>And if you want to make it a library feature: Prefix these
macros by STD_<br>
</div>
</blockquote>
I would accept a macro STD_SYNCHRONIZED if there is no better
option. See my post on Let in statement and unamed variables which
could allow you to write <br>
<br>
auto = synchronize(m) : <br>
{<br>
// access to protected data<br>
}<br>
<br>
without introducing any new keyword.<br>
<br>
Vicente<br>
<br>
<br>
[1] "Enforcing Correct Mutex Usage with Synchronized Values" from
Anthony William here <a class="moz-txt-link-freetext"
href="http://www.drdobbs.com/cpp/enforcing-correct-mutex-usage-with-synch/225200269">http://www.drdobbs.com/cpp/enforcing-correct-mutex-usage-with-synch/225200269</a>.
<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------060600020906040804010809--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Tue, 4 Dec 2012 23:54:34 -0500
Raw View
On Thu, Nov 29, 2012 at 5:37 PM, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
> Le 29/11/12 18:07, Tony V E a =E9crit :
>
>> On Wed, Nov 28, 2012 at 10:13 PM, Ben Craig <ben.craig@gmail.com> wrote:
>>>
>>>
>> I would add that (IMO) the synchronized operator-> is harmful. It
>> leads to misunderstandings like:
>>
>> Synchronized<Container> container;
>> ...
>> if (!container->empty()) {
>> auto item =3D container->front();
>> ...
>> }
>>
>> hey the container was synchronized, why does this crash (but only rarely=
)?
>>
>> Maybe this is programmer error, but I think we have enough foot-guns
>> already. If it was my library, I'd only offer the SYNCHRONIZED macro,
>> not the single-function shortcuts.
>>
>>
> Yes, there is an error here. Do you mean that the error would be more
> visible if a synchronize function was used instead, as in
>
> if (!container.synchronize().empty()) {
> auto item =3D container.synchronize().front();
> ...
> }
>
> Vicente
>
Yes, that would hopefully make it more obvious.
I might go one further and force them to use STD_SYNCHRONIZE or
whatever it may be. Something that leans towards a *block* not a
single line. I don't like single-line lock code. I *like* that a
lock is indented and has { ... } brackets. Makes it easier to see,
and I think clearly seeing when locks are held and not held, what code
is protected and what is not, is vital.
Tony
--=20
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 08 Dec 2012 14:19:03 +0100
Raw View
Le 05/12/12 05:54, Tony V E a =E9crit :
> On Thu, Nov 29, 2012 at 5:37 PM, Vicente J. Botet Escriba
> <vicente.botet@wanadoo.fr> wrote:
>> Le 29/11/12 18:07, Tony V E a =E9crit :
>>
>>> On Wed, Nov 28, 2012 at 10:13 PM, Ben Craig <ben.craig@gmail.com> wrote=
:
>>>>
>>> I would add that (IMO) the synchronized operator-> is harmful. It
>>> leads to misunderstandings like:
>>>
>>> Synchronized<Container> container;
>>> ...
>>> if (!container->empty()) {
>>> auto item =3D container->front();
>>> ...
>>> }
>>>
>>> hey the container was synchronized, why does this crash (but only rarel=
y)?
>>>
>>> Maybe this is programmer error, but I think we have enough foot-guns
>>> already. If it was my library, I'd only offer the SYNCHRONIZED macro,
>>> not the single-function shortcuts.
>>>
>>>
>> Yes, there is an error here. Do you mean that the error would be more
>> visible if a synchronize function was used instead, as in
>>
>> if (!container.synchronize().empty()) {
>> auto item =3D container.synchronize().front();
>> ...
>> }
>>
>> Vicente
>>
> Yes, that would hopefully make it more obvious.
> I might go one further and force them to use STD_SYNCHRONIZE or
> whatever it may be. Something that leans towards a *block* not a
> single line. I don't like single-line lock code. I *like* that a
> lock is indented and has { ... } brackets. Makes it easier to see,
> and I think clearly seeing when locks are held and not held, what code
> is protected and what is not, is vital.
>
>
I like the macro approach but I don't think the committee will accept to=20
start adding macros in the standard. I let you make a concrete proposal.
Vicente
--=20
.