220 17639 <9A3E0561DCF227429F72080EA81ADBC95084454075@TUS1XCHEVSPIN42.SYMC.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: Thu, 30 Apr 2015 14:12:35 -0700 Lines: 466 Approved: news@gmane.org Message-ID: <9A3E0561DCF227429F72080EA81ADBC95084454075@TUS1XCHEVSPIN42.SYMC.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_9A3E0561DCF227429F72080EA81ADBC95084454075TUS1XCHEVSPIN_" X-Trace: ger.gmane.org 1430428386 32749 80.91.229.3 (30 Apr 2015 21:13:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 Apr 2015 21:13:06 +0000 (UTC) To: Arthur O'Dwyer , "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBDRKVPVDWYNBBSNVRKVAKGQEVXQID7Q@isocpp.org Thu Apr 30 23:12:46 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wi0-f198.google.com ([209.85.212.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YnvlC-0001LW-78 for gclcip-std-proposals@m.gmane.org; Thu, 30 Apr 2015 23:12:42 +0200 Original-Received: by wicmx19 with SMTP id mx19sf9042829wic.3 for ; Thu, 30 Apr 2015 14:12:41 -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: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=Sijft1BKa/GMTu4ww96fIMxkfBwRWaLMRUCMjR/+PYg=; b=Xd16F201OZB01aJ8RufrwMO80VARkaRCSOmTZUCwBEvKKO2azmbZwmrFGGaRYBYWWH kFfcjDeBV30/vuvq7gwe6Vi/m1c74svUfMk/Q7KZqi1L2xLromM4zJHcgO78dGV9Jg0F asKOckPB6CH5cG0+QBWQEsZLMWB6MB29R7CHcewvYC17x8VLFrT0aMWOyXibLE5YiFah axei3pEmd6KU1BWdfC2vCeczd24V5nTZPPktat4Dfq0927SqRAvbf/tpHjOquAN/qnJ4 QBB28y/pnCl7k0wqGiD7BTfok26LC3IK7R X-Gm-Message-State: ALoCoQnwhiMqdlK841M2FULeNOs9GbNTnBbQkjw+nNFqtUTQX8/caZJdqpSl0NG2FBmVUKB1RQa6 X-Received: by 10.112.219.200 with SMTP id pq8mr4032714lbc.7.1430428361810; Thu, 30 Apr 2015 14:12:41 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.104.135 with SMTP id ge7ls230856wib.25.gmail; Thu, 30 Apr 2015 14:12:40 -0700 (PDT) X-Received: by 10.194.173.226 with SMTP id bn2mr12305192wjc.148.1430428360777; Thu, 30 Apr 2015 14:12:40 -0700 (PDT) Original-Received: from ecl1mtaoutpex01.symantec.com (ecl1mtaoutpex01.symantec.com. [166.98.1.209]) by mx.google.com with ESMTPS id y14si5426917wju.139.2015.04.30.14.12.40 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 30 Apr 2015 14:12:40 -0700 (PDT) Received-SPF: pass (google.com: domain of mike_spertus@symantec.com designates 166.98.1.209 as permitted sender) client-ip=166.98.1.209; X-AuditID: a66201d1-f79226d000006a45-a0-55429ac77e30 Original-Received: from ecl1mtahubpin01.ges.symantec.com (ecl1mtahubpin01.ges.symantec.com [10.48.69.201]) by ecl1mtaoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id 62.1C.27205.7CA92455; Thu, 30 Apr 2015 21:12:39 +0000 (GMT) Original-Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by ecl1mtahubpin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1Ynvl8-00007n-4W; Thu, 30 Apr 2015 21:12:38 +0000 Original-Received: from TUS1XCHEVSPIN42.SYMC.SYMANTEC.COM ([155.64.221.73]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Thu, 30 Apr 2015 14:12:40 -0700 Thread-Topic: Comments on N4470 "Variadic lock_guard" Thread-Index: AdCDh/PH6yHK82OCSkWoBuF1/7z/GwAADDSg 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+NgFlrBIsWRmVeSWpSXmKPExsXCZeB6Uvf4LKdQg11XOSyerlzBYvH1epQD k8fOWXfZPSa+n8kSwBTFZZOSmpNZllqkb5fAlfFi6iSmghU9TBU/HjYxNzAuaWXqYuTkkBAw kdh48iwjhC0mceHeerYuRi4OIYF3jBIP+05COa8YJbbPms0C4axklDh9dAUrSAubgKHE5A/n WEBsEYF0iWUrloONYhFQlVjbO5kdxBYGWtHa+wOqxlRi4e6PzF2MHEC2kcTBk7ogJq9AlMTa XSEQ4w8xSqzfdRTsOk4BO4nORZOYQWxGoOu+n1oDFmcWEJe49WQ+1AcCEkv2nGeGsEUlXj7+ xwpRLypxp309I0R9vsSKGbPA6nkFBCVOznzCMoFRdBaSUbOQlM1CUjYL6DxmAU2gk/QhShQl pnQ/ZIewNSRa58xlRxZfwMi+ilEmNTnHMLckMb+0pCC1wsBQr7gyNxEYe8l6yfm5mxiB8bcs ifHiDsYLh3UPMQpwMCrx8FZ3O4UKsSaWAVUC/c/BrCTCKzUDKMSbklhZlVqUH19UmpNafIhR moNFSZz3UadoqJBAemJJanZqakFqEUyWiYNTqoGxaPLSl/NXJGQd55R5tGC21al+v12+ie3/ 0yT5FjGcjZ/hZbHa64bxbtmlFuILF+XumRmSd3TZt52y7a6uNx19BR/KHduZXLXeb1XwhPUv ShzMze7c0Jp9v6DgSD9bfmvEe5mcF62WQlvzFz7O37Q6sO6thStLu8mlj6ZTV3LYp//5vtvz wB1lJZbijERDLeai4kQA7uJcmrsCAAA= 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 166.98.1.209 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:17639 Archived-At: --_000_9A3E0561DCF227429F72080EA81ADBC95084454075TUS1XCHEVSPIN_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Comments in Green From: Arthur O'Dwyer [mailto:arthur.j.odwyer@gmail.com] Sent: Thursday, April 30, 2015 3:55 PM To: std-proposals@isocpp.org Cc: Michael Spertus; arthur.j.odwyer@gmail.com Subject: Re: Comments on N4470 "Variadic lock_guard" 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. :) Great. I would object to the proposal without this as well =E2=98=BA 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. I=E2=80=99m not averse to making lock_guard movable. 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. I didn=E2=80=99t get around to including unique_lock in this proposal, as t= here are some subtleties, but I may do a proposal later 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...? Here is a typical example from the paper due Howard, which I think occurs = more often than not when a programmer writes a =E2=80=9Csynchronized class= =E2=80=9D class X { using Mutex =3D std::shared_timed_mutex; using ReadLock =3D std::shared_lock; mutable Mutex mut_; // more data public: // ... X& operator=3D(const X& x) { if (this !=3D&x) { ReadLock rl(x.mut_, std::defer_lock); std::lock_guard lck(mut_, rl); // assign data ... } return *this; } // ... }; 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? I think std::lock is a lot better for the vast majority of people than roll= ing their own, but agree this is off topic, so let=E2=80=99s discuss over b= eer in Lenexa=E2=80=A6 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_9A3E0561DCF227429F72080EA81ADBC95084454075TUS1XCHEVSPIN_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Com= ments in Green

 

From: Arthur O'Dwyer [mailto:arthur.j.odwye= r@gmail.com]
Sent: Thursday, April 30, 2015 3:55 PM
To: std-proposals@isocpp.org
Cc: Michael Spertus; arthur.j.odwyer@g= mail.com
Subject: Re: Comments on N4470 "Variadic lock_guard= "

 

=

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

Thanks for your comments.  Arthur,

1.&nbs= p;      Absolutely, the proposal is me= ant 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 submi= tting, but it was too late=E2=80=A6 I did give my students an extra credit = problem to find the mistake in the paper).

Aha. This definitely removes 70% of my ob= jection to the proposal. :)

<= o:p> 

 Great. I would object to the proposal without this as well J

2.       I conside= red requiring that all the mutex types be the same as you suggest, but some= of the 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 suggesting that all the Mutexes... should have to be the same; I = was just pointing out that in the most common case, where they are t= he 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 impleme= nt 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<M>'s constructor to take any number of argumen= ts as long as all of them are of type M, or you could have = lock_guard do type erasure so that the type inside the angle bracket= s no longer particularly matters... Those both have obvious hurdles (where = do you keep the extra arguments? type erasure requires heap allocation) but= that's the general direction in which the rabbit hole would take us.<= /o:p>

 

 

&nb= sp;

3. =       If N4471 is adopted, then you do= n=E2=80=99t need to worry about template arguments.
auto guard =3D lock_= guard(mtx1, mtx2);

N4471 (type deduction for constructors) is astronomically unlikel= y to get accepted IMHO, due to the "Challenges" identified in the= proposal and the lack of implementations or proposed wording.

Without N4471, we could propose making lock_guard move-constructibl= e (which I think is fine in practice because a lock_guard is just a bundle of references, righ= t?), and then we'd have this syntax:

 

    auto guard =3D= make_lock_guard(mtx1, mtx2);=

<= o:p> 

4.       Even without N4471, sinc= e 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 overhead isn=E2=80=99= t excessive.

IMHO the notational overhead for 2 mutexes is excessive =E2=80= =94 that's what I meant by "ugly syntax". But this is a minor poi= nt, and could be solved by make_l= ock_guard above.

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F49= 7D'> 

I=E2=80=99m not averse to making lock_guard movable.

 

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 w= ay to avoid specifying the template arguments. (Since lock_guard is not mov= able, you can=E2=80=99t do this with lock_guards).

Your proposal doesn't actually sp= ecify a variadic unique_lock, though, does it?  If the concepts are coupled, maybe they should b= e proposed together.

I didn=E2=80=99t get around to including unique_lock = in this proposal, as there are some subtleties, but I may do a proposal lat= er

 

6.=    &nbs= p;   While 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 are common in practices. C++ in general has the = philosophy of offering both low-level primitives and high-level abstraction= s. 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 par= ticular, I think the built-in deadlock avoidance (Once the wording embarras= sment from #1 above is fixed!) will result in more reliable programs in pra= ctice, if only because many user-defined types follow the rule of three=E2= =80=99s imprecation to provide assignment operators.

<= /div>

Can you elaborate on what you m= ean by "if only because ... assignment operators"?  I don't = see how assignment operators and the Rule of Three are related to the lock_= guard proposal at all...?

&nb= sp;Here is a typical example from the paper d= ue Howard, which I think occurs more often than not when a programmer write= s a =E2=80=9Csynchronized class=E2=80=9D

 

class X {

=C2=A0=C2=A0using Mutex =3D std::shar= ed_timed_mutex;

=C2=A0using ReadLo= ck =3D std::shared_lock<Mutex>;

=C2=A0 mutable Mutex mut_;

=C2= =A0=C2=A0// more data

public: // ..= ..

=C2=A0X& operator=3D(const X= & x) {

=C2=A0=C2=A0 =C2=A0if (t= his !=3D&x) {

=C2=A0=C2=A0=C2= =A0=C2=A0 =C2=A0ReadLock rl(x.mut_, std::defer_lock);

=

=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0std::lock_guard<Mutex,= ReadLock> lck(mut_, rl);

=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0// assign data ...

=C2=A0=C2=A0=C2=A0 }

<= span style=3D'font-size:11.0pt;font-family:"Courier New";color:#00B050'>=C2= =A0 =C2=A0=C2=A0return *this;

=C2= =A0=C2=A0}

=C2=A0=C2=A0// ...

};

8.       <= /span>I=E2=80=99m having trouble seeing any reason we shouldn=E2=80=99= t allow lock_guard to be variadic. The proposal is easy to ignore if you do= n=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 underspec= ified. ;)  This is way off-topic, but I wonder how many people trust <= span style=3D'font-family:"Courier New"'>std::lock in practice, and = how many simply roll their own lock-ordering scheme and/or exponential back= off scheme and/or whatever other schemes are popular for avoiding deadlock.= I don't do synchronization stuff myself, but I wonder whether people who d= o, actually trust their standard library's std::lock to avoid livelock. And when they move to a diffe= rent platform, do they see the same performance characteristics?=

&nbs= p;

I think std::lock is a lot bet= ter for the vast majority of people than rolling their own, but agree this = is off topic, so let=E2=80=99s discuss over beer in Lenexa=E2=80=A6

 

<= 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 tha= t supports transactions or whatever, instead of continuing to mess around w= ith raw locks. The question is whether this proposal is making lock_guard look more like a su= per robust and DWIM thing and attractive to newbies, when in fact it= 's still very dangerous under the hood.

 

=E2=80=93= Arthur

--

---
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_9A3E0561DCF227429F72080EA81ADBC95084454075TUS1XCHEVSPIN_-- .