220 17684 <6C4493F2-142D-417E-A30C-AC4A4D53BFA5@symantec.com> article Path: news.gmane.org!not-for-mail From: Michael Spertus Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Comments on N4470 "Variadic lock_guard" Date: Mon, 4 May 2015 11:19:50 -0700 Lines: 311 Approved: news@gmane.org Message-ID: <6C4493F2-142D-417E-A30C-AC4A4D53BFA5@symantec.com> References: <9A3E0561DCF227429F72080EA81ADBC95084453ECA@TUS1XCHEVSPIN42.SYMC.SYMANTEC.COM> <5199fc13-1dae-4a11-907b-159d98487c9d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_6C4493F2142D417EA30CAC4A4D53BFA5symanteccom_" X-Trace: ger.gmane.org 1430763629 24683 80.91.229.3 (4 May 2015 18:20:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 May 2015 18:20:29 +0000 (UTC) Cc: "std-proposals@isocpp.org" To: Arthur O'Dwyer Original-X-From: std-proposals+bncBDRKVPVDWYNBBXHQT2VAKGQEECZE3EY@isocpp.org Mon May 04 20:20:16 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qg0-f69.google.com ([209.85.192.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YpKyT-0002Oh-RM for gclcip-std-proposals@m.gmane.org; Mon, 04 May 2015 20:20:14 +0200 Original-Received: by qgeb100 with SMTP id b100sf91783919qge.3 for ; Mon, 04 May 2015 11:20:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:date:subject:thread-topic :thread-index:message-id:references:in-reply-to:accept-language :content-language:acceptlanguage:content-type:mime-version :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=VFN7H1dFzYCx8ziVRkcSoT+xcd7FxxJaYin6B0RaBLo=; b=OzgzgjlMInLU47Dqa8xMnzxaBjyzfNhLEekGOvr/ErJtJWW/s0aTWZwbaFd7vgbJRN cXjcCPhzbZqDnIa4Yt3Eq8kxaot1VTOgSYIuQDhJRZ5pGVbL5Pfl7h2vxuwzOSTzXW9z XL7S72rvZhJCFIWCMAInNoPtSAPXBn72fQ63AYvEyJWmTtMZj1vS2aqtmINdiQpok8Yt cbgzrEy2SvFCNW1CYxYxOsrAuJaQn+tLuuf6xck5vWKJfuSM8s5ElWutf5ShLE/lIY05 uRqsOJUYpzfdQe1rfETHI8bTiFopQFc X-Gm-Message-State: ALoCoQmwQCR29r8vj0x3uS05GePY/hvRvTvT3MpHc5JQrpBtd9ciuO3k3bbPDRZVfvTs/I61S4RE X-Received: by 10.140.152.2 with SMTP id 2mr42439424qhy.3.1430763612694; Mon, 04 May 2015 11:20:12 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.60.100 with SMTP id g4ls1279140igr.16.gmail; Mon, 04 May 2015 11:20:11 -0700 (PDT) X-Received: by 10.66.234.134 with SMTP id ue6mr44223412pac.146.1430763611833; Mon, 04 May 2015 11:20:11 -0700 (PDT) Original-Received: from tus1smtoutpex03.symantec.com (tus1smtoutpex03.symantec.com. [216.10.195.243]) by mx.google.com with ESMTPS id y3si20780355pbt.136.2015.05.04.11.20.11 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 May 2015 11:20:11 -0700 (PDT) Received-SPF: pass (google.com: domain of mike_spertus@symantec.com designates 216.10.195.243 as permitted sender) client-ip=216.10.195.243; X-AuditID: d80ac3f3-f79206d000005d93-da-5547b85ab4f8 Original-Received: from ecl1mtahubpin02.ges.symantec.com (ecl1mtahubpin02.ges.symantec.com [10.48.69.202]) by tus1smtoutpex03.symantec.com (Symantec Brightmail Gateway out) with SMTP id B6.E5.23955.A58B7455; Mon, 4 May 2015 19:20:11 +0100 (BST) Original-Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by ecl1mtahubpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1YpKyP-0002um-PV; Mon, 04 May 2015 14:20:09 -0400 Original-Received: from TUS1XCHEVSPIN42.SYMC.SYMANTEC.COM ([155.64.221.74]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Mon, 4 May 2015 11:20:10 -0700 Thread-Topic: Comments on N4470 "Variadic lock_guard" Thread-Index: AdCGlvP2VwG461mNSYaK6roPzmK3qw== In-Reply-To: <5199fc13-1dae-4a11-907b-159d98487c9d@isocpp.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsXCZeB6Sjd6h3uowcoDbBZPV65gsfh6PcqB yWPnrLvsHhPfz2QJYIrisklJzcksSy3St0vgyvh09ARrwZMtjBXPp2xgbWD8s56xi5GTQ0LA RGLS53fMELaYxIV769m6GLk4hATeMUrMeNDKDuG8YpSYeGgSK4SzglFi1bmjTCAtbAKGEpM/ nGPpYuTgEBHQk5h0yBgkzCxgKXFpyiIWEJtFQEWib9MlsG3CQNu+LrkBtk1EwFRi4e6PULae xK1Xi8BsXgF7iWVztrNA7DrEKLF+F8QuTgE7ic5Fk8CKGIFO/X5qDRPEMnGJW0/mM0G8ICCx ZM95qHdEJV4+/scKUS8qcacd5GUOoPpkib0zcyF2CUqcnPmEZQKj2Cwkk2YhVM1CUgUR1gQ6 SB+iWlFiSvdDdghbQ6J1zlx2ZPEFjOyrGGVKSosNi3NL8ktLClIrDIz1iitzE4ERmayXnJ+7 iREYlTe4Dn/ewfh7j+MhRgEORiUeXtfN7qFCrIllQJVA33MwK4nw3lkLFOJNSaysSi3Kjy8q zUktPsQozcGiJM77p1M0VEggPbEkNTs1tSC1CCbLxMEp1cDob6fl0HxmYoWR6Y1304qPnbC7 ms1/Yc/sD5Hnct50bQhpLlBZo3ammWNmddi8jc8WSnZ9l7u1Pljhamh7xvOX0+/dfbrKYO38 nyo7H8czHdXj5Ej+OP3H7Ix/C/O+uPFM213jqLA9ot0/0m7/RetPp17sU9a6Kv/35k95yd1L dXZteKt1JJH/qxJLcUaioRZzUXEiAOQnnZbGAgAA X-Original-Sender: mike_spertus@symantec.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of mike_spertus@symantec.com designates 216.10.195.243 as permitted sender) smtp.mail=mike_spertus@symantec.com; dmarc=pass (p=NONE dis=NONE) header.from=symantec.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:17684 Archived-At: --_000_6C4493F2142D417EA30CAC4A4D53BFA5symanteccom_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Update version is on the wiki and we will discuss right after lunch Sent from my iPhone On Apr 30, 2015, at 3:55 PM, Arthur O'Dwyer > wrote: On Thursday, April 30, 2015 at 6:44:50 AM UTC-7, Michael Spertus wrote: Thanks for your comments. Arthur, 1. Absolutely, the proposal is meant to be deadlock-free, and I just = embarrassingly put in the wording wrong. Corrected wording will be on the w= iki. (I realized this right after submitting, but it was too late=E2=80=A6 = I did give my students an extra credit problem to find the mistake in the p= aper). Aha. This definitely removes 70% of my objection to the proposal. :) 2. I considered requiring that all the mutex types be the same as you= suggest, but some of the most important use cases require different lock t= ypes (like Howard=E2=80=99s operator=3D example in the paper), and it just = seems inaccurate to do otherwise. I wasn't necessarily suggesting that all the Mutexes... should have to be t= he same; I was just pointing out that in the most common case, where they a= re the same, it's ugly to force the user to write the same type many times = in a row. I deliberately didn't go down the rabbit hole of how to implemen= t the prettier syntax, because I figured I had a strictly better idea with = lock_tuple =E2=80=94 but you can certainly use SFINAE to allow lock_guard's constructor to take any number of arguments as long as all of them are = of type M, or you could have lock_guard do type erasure so that the type in= side the angle brackets no longer particularly matters... Those both have o= bvious hurdles (where do you keep the extra arguments? type erasure require= s heap allocation) but that's the general direction in which the rabbit hol= e would take us. 3. If N4471 is adopted, then you don=E2=80=99t need to worry about te= mplate arguments. auto guard =3D lock_guard(mtx1, mtx2); N4471 (type deduction for constructors) is astronomically unlikely to get a= ccepted IMHO, due to the "Challenges" identified in the proposal and the la= ck of implementations or proposed wording. Without N4471, we could propose making lock_guard move-constructible (which= I think is fine in practice because a lock_guard is just a bundle of refer= ences, right?), and then we'd have this syntax: auto guard =3D make_lock_guard(mtx1, mtx2); 4. Even without N4471, since all of the common use cases we could thi= nk of involve 0, 1, or 2 mutexes (note that 0 locks is useful as well), the= notational overhead isn=E2=80=99t excessive. IMHO the notational overhead for 2 mutexes is excessive =E2=80=94 that's wh= at I meant by "ugly syntax". But this is a minor point, and could be solved= by make_lock_guard above. 5. It seems like unique_lock might also want to work with any number = of mutexes. In that case, a make_unique_lock(=E2=80=A6) would be another wa= y to avoid specifying the template arguments. (Since lock_guard is not mova= ble, you can=E2=80=99t do this with lock_guards). Your proposal doesn't actually specify a variadic unique_lock, though, does= it? If the concepts are coupled, maybe they should be proposed together. 6. While I sympathize with your desire to avoid raw locking primitive= s, I think the use cases in the paper are appropriate and of course, explic= it locks are common in practices. C++ in general has the philosophy of offe= ring both low-level primitives and high-level abstractions. In any case, if= we choose to provide raw locking primitives, I think the relevant question= is whether or not they are better if variadic (also see #8 below). 7. In particular, I think the built-in deadlock avoidance (Once the w= ording embarrassment from #1 above is fixed!) will result in more reliable = programs in practice, if only because many user-defined types follow the ru= le of three=E2=80=99s imprecation to provide assignment operators. Can you elaborate on what you mean by "if only because ... assignment opera= tors"? I don't see how assignment operators and the Rule of Three are rela= ted to the lock_guard proposal at all...? 8. I=E2=80=99m having trouble seeing any reason we shouldn=E2=80=99t = allow lock_guard to be variadic. The proposal is easy to ignore if you don= =E2=80=99t like it, and IMO doesn=E2=80=99t add conceptual complexity. =E2= =80=9Cstd::lock_guard can manage a set of locks of diverse types, just like= std::lock=E2=80=9D. I=E2=80=99ve never heard any of my students or coworke= rs say that std::lock is more confusing because it was variadic. std::lock is confusing because it's underspecified. ;) This is way off-top= ic, but I wonder how many people trust std::lock in practice, and how many = simply roll their own lock-ordering scheme and/or exponential backoff schem= e and/or whatever other schemes are popular for avoiding deadlock. I don't = do synchronization stuff myself, but I wonder whether people who do, actual= ly trust their standard library's std::lock to avoid livelock. And when the= y move to a different platform, do they see the same performance characteri= stics? The value of std::lock_guard is that it's super simple, just like std::mute= x. If I want a super simple thing, I use lock_guard; if I want a super robu= st and DWIM thing, I use some higher-level system that supports transaction= s or whatever, instead of continuing to mess around with raw locks. The que= stion is whether this proposal is making lock_guard look more like a super = robust and DWIM thing and attractive to newbies, when in fact it's still ve= ry dangerous under the hood. =E2=80=93Arthur --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --_000_6C4493F2142D417EA30CAC4A4D53BFA5symanteccom_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Update version is on the wiki and = we will discuss right after lunch

Sent from my iPhone

= On Apr 30, 2015, at 3:55 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:

On Thursday, April 30, 2015 at= 6:44:50 AM UTC-7, Michael Spertus wrote:

Thanks for your comments.  Arthu= r,

1.       Absolutely, the proposal is meant to be deadlock-free, and= I just embarrassingly put in the wording wrong. Corrected wording will be = on the wiki. (I realized this right after submitting, but it was too late= =E2=80=A6 I did give my students an extra credit problem to find the mistak= e in the paper).

Aha. This definitely rem= oves 70% of my objection to the proposal. :)

 = ;

= 2.  =      I considered r= equiring that all the mutex types be the same as you suggest, but some of t= he most important use cases require different lock types (like Howard=E2=80= =99s operator=3D example in the paper), and it just seems inaccurate to do = otherwise.

I wasn't necessarily suggestin= g that all the Mutexes... shou= ld have to be the same; I was just pointing out that in the most com= mon case, where they are the same, it's ugly to force the user to wr= ite the same type many times in a row.  I deliberately didn't go down = the rabbit hole of how to implement the prettier syntax, because I figured = I had a strictly better idea with loc= k_tuple =E2=80=94 but you can certainly use SFINAE to allow lock_guard<M>'s constructor to t= ake any number of arguments as long as all of them are of type M, or you could have lock_guard do type erasure so that the type insid= e the angle brackets no longer particularly matters... Those both have obvi= ous hurdles (where do you keep the extra arguments? type erasure requires h= eap allocation) but that's the general direction in which the rabbit hole w= ould take us.


 

3.    &nbs= p;  If N4471 is adopted, then you = don=E2=80=99t need to worry about template arguments.
auto guard =3D loc= k_guard(mtx1, mtx2);

N4471 (type deductio= n for constructors) is astronomically unlikely to get accepted IMHO, due to= the "Challenges" identified in the proposal and the lack of implementation= s or proposed wording.
Without N4471, we could propose making lock_guard move-constructible (wh= ich I think is fine in practice because a lock_guard is just a bundle of references, right?), and = then we'd have this syntax:

=     auto g= uard =3D make_lock_g= uard(mtx1, mtx2);

&n= bsp;

4. = ;      Even wi= thout N4471, since all of the common use cases we could think of involve 0,= 1, or 2 mutexes (note that 0 locks is useful as well), the notational over= head isn=E2=80=99t excessive.

IMHO the no= tational overhead for 2 mutexes is excessive =E2=80=94 that's what I= meant by "ugly syntax". But this is a minor point, and could be solved by = make_lock_guard above.


5.       It seems like unique_lock might also want to work with any number of= mutexes. In that case, a make_unique_lock(=E2=80=A6) would be another way = to avoid specifying the template arguments. (Since lock_guard is not movabl= e, you can=E2=80=99t do this with lock_guards).

Your proposal doesn't actually specify a variadic unique_lock, though, does it?  If the conce= pts are coupled, maybe they should be proposed together.

 

6.=        Wh= ile I sympathize with your desire to avoid raw locking primitives, I think = the use cases in the paper are appropriate and of course, explicit locks ar= e common in practices. C++ in general has the philosophy of offering both l= ow-level primitives and high-level abstractions. In any case, if we choose = to provide raw locking primitives, I think the relevant question is whether= or not they are better if variadic (also see #8 below).

7.&n= bsp;      In p= articular, I think the built-in deadlock avoidance (Once the wording embarr= assment from #1 above is fixed!) will result in more reliable programs in p= ractice, if only because many user-defined types follow the rule of three= =E2=80=99s imprecation to provide assignment operators.

Can you elaborate on what you mean by "if only because ... a= ssignment operators"?  I don't see how assignment operators and the Ru= le of Three are related to the lock_guard proposal at all...?
&nb= sp;

8. &n= bsp;     I=E2=80=99= m having trouble seeing any reason we shouldn=E2=80=99t allow lock_guard to= be variadic. The proposal is easy to ignore if you don=E2=80=99t like it, = and IMO doesn=E2=80=99t add conceptual complexity. =E2=80=9Cstd::lock_guard= can manage a set of locks of diverse types, just like std::lock=E2=80=9D. = I=E2=80=99ve never heard any of my students or coworkers say that std::lock= is more confusing because it was variadic.

std::lock is confusing beca= use it's underspecified. ;)  This is way off-topic, but I wonder how m= any people trust std::lock in = practice, and how many simply roll their own lock-ordering scheme and/or ex= ponential backoff scheme and/or whatever other schemes are popular for avoi= ding deadlock. I don't do synchronization stuff myself, but I wonder whethe= r people who do, actually trust their standard library's std::lock to avoid livelock. And when they move = to a different platform, do they see the same performance characteristics?<= /div>

The value of std::lock_guard is that it's super simple, just like std::mutex. If I want a super simple thing, = I use lock_guard; if I want a = super robust and DWIM thing, I use some higher-level system that supports t= ransactions or whatever, instead of continuing to mess around with raw lock= s. The question is whether this proposal is making lock_guard look more like a super robust and DW= IM thing and attractive to newbies, when in fact it's still very dan= gerous under the hood.

=E2=80=93Arthur
=

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--_000_6C4493F2142D417EA30CAC4A4D53BFA5symanteccom_-- .