220 17609 <9A3E0561DCF227429F72080EA81ADBC95084453ECA@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 06:44:26 -0700 Lines: 964 Approved: news@gmane.org Message-ID: <9A3E0561DCF227429F72080EA81ADBC95084453ECA@TUS1XCHEVSPIN42.SYMC.SYMANTEC.COM> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_9A3E0561DCF227429F72080EA81ADBC95084453ECATUS1XCHEVSPIN_" X-Trace: ger.gmane.org 1430401502 12306 80.91.229.3 (30 Apr 2015 13:45:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 Apr 2015 13:45:02 +0000 (UTC) To: Arthur O'Dwyer , "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBDRKVPVDWYNBBUPDRCVAKGQEM7QKEPQ@isocpp.org Thu Apr 30 15:44:51 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wi0-f197.google.com ([209.85.212.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ynolm-0003EH-LA for gclcip-std-proposals@m.gmane.org; Thu, 30 Apr 2015 15:44:50 +0200 Original-Received: by wiun10 with SMTP id n10sf4793984wiu.1 for ; Thu, 30 Apr 2015 06:44:50 -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=JuNWDM7l3k7Swhbi6oPQwYPJ64WRN39cBc3efJ4pKuE=; b=fTWfUeykllx8dgb2wfyrvRLw+mLxWGd5+JZa5W2w0FCle64N1tjj2n6PKQG7rRHle2 xDhUf3giplvuYw0PzXwijFRcx8ve+1JXYjtr1Gc86txIR+xhRauruLTBVM9R951nGZAu pMmthzGo9U70YTSYE9ImWTvx96+YFO4dQRA+hY+SWzEvhzjeqG+lmuzVjyxdEI6B+ssv HYyfQ+ZEG7+riqquJCwUGvKxZHqUZ06/KwmZoumjHpjQC/HjQaiGcoN0kW1pxUb2q+zf JN+ZPm389iVN+dSbPFBvcjcvZz19CRsgE2 X-Gm-Message-State: ALoCoQlryZ8Lx5ukU1SRQVl2s2lV/wBTsyaDZz5wboWEknLvsI3nxgj4ifEj1XHk1ztDCUDNkxjE X-Received: by 10.152.8.17 with SMTP id n17mr2599800laa.0.1430401490053; Thu, 30 Apr 2015 06:44:50 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.211.205 with SMTP id ne13ls132047wic.36.gmail; Thu, 30 Apr 2015 06:44:48 -0700 (PDT) X-Received: by 10.194.175.70 with SMTP id by6mr9029150wjc.42.1430401488742; Thu, 30 Apr 2015 06:44:48 -0700 (PDT) Original-Received: from ecl1mtaoutpex02.symantec.com (ecl1mtaoutpex02.symantec.com. [166.98.1.210]) by mx.google.com with ESMTPS id dx2si2934347wib.2.2015.04.30.06.44.47 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 30 Apr 2015 06:44:48 -0700 (PDT) Received-SPF: pass (google.com: domain of mike_spertus@symantec.com designates 166.98.1.210 as permitted sender) client-ip=166.98.1.210; X-AuditID: a66201d2-f78fe6d000005a74-7c-554231cecd05 Original-Received: from ecl1mtahubpin02.ges.symantec.com (ecl1mtahubpin02.ges.symantec.com [10.48.69.202]) by ecl1mtaoutpex02.symantec.com (Symantec Brightmail Gateway out) with SMTP id 44.BE.23156.EC132455; Thu, 30 Apr 2015 13:44:46 +0000 (GMT) Original-Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by ecl1mtahubpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1Ynolg-0007CE-WE; Thu, 30 Apr 2015 09:44:45 -0400 Original-Received: from TUS1XCHEVSPIN42.SYMC.SYMANTEC.COM ([155.64.221.73]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Thu, 30 Apr 2015 06:44:43 -0700 Thread-Topic: Comments on N4470 "Variadic lock_guard" Thread-Index: AdCDLml1n7EZQ/+dRLCzq4x31uxCLQAF1J4A In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsXCZeB6SvecoVOowfOvChZPV65gsfh6PcqB yWPnrLvsHhPfz2QJYIrisklJzcksSy3St0vgypj4VrBgxguWikMLn7M1MM65wdLFyMkhIWAi 8fBlJxOELSZx4d56ti5GLg4hgXeMEqffPmGHcF4xSvy91s8M4axklLjQNZcNpIVNwFBi8odz YKNEBNIllq1YzghiswioSjzpvwBWIwy0orX3B1SNqcTC3R+ZIWwjidePNoHFeQWiJCZ2PAaL CwnYSlw60wzWyylgJ9F++xKYzQh03vdTa8BOZRYQl7j1ZD7U2QISS/acZ4awRSVePv7HClEv KnGnfT0jRH2+ROOCl8wQuwQlTs58wjKBUXQWklGzkJTNQlI2i5EDKK4psX6XPkSJosSU7ofs ELaGROucuezI4gsY2VcxyqQm5xjmliTml5YUpFYYGOkVV+YmAmMvWS85P3cTIzD+liUxXtrB eP+w7iFGAQ5GJR7ec3JOoUKsiWVAlYcYJTiYlUR4xRSAQrwpiZVVqUX58UWlOanFhxilOViU xHkfdoqGCgmkJ5akZqemFqQWwWSZODilGhgdsic8ZThXd/Ei82H+/j3LTLym1KpuTTG7Et42 /7t4YqmE0rTCiANFJ5+uSApfNF3qwMrdMlpHDLWELFI7tpfnfpIpKJdalnviwCXmH5cWJcqy V/eZNqelu+m4//1i+O7xMrMXq5ZqWknbMXYm/e0+dMz+wMEgrWv6mo7Ou28HfJz7Xuda+3sl luKMREMt5qLiRAAAvJuguwIAAA== 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.210 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:17609 Archived-At: --_000_9A3E0561DCF227429F72080EA81ADBC95084453ECATUS1XCHEVSPIN_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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). 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. 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); 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. 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). 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. 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. What do you think, Mike From: Arthur O'Dwyer [mailto:arthur.j.odwyer@gmail.com] Sent: Thursday, April 30, 2015 5:14 AM To: std-proposals@isocpp.org Cc: Michael Spertus Subject: Comments on N4470 "Variadic lock_guard" I was just reading Mike Spertus' N4470 "Variadic lock_guard": http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4470.html My first impression was, "Wow, this is a slam-dunk obvious proposal... of c= ourse lock_guard should be able to take multiple arguments!" But the further I read, the uglier it seems, both in syntax and in semantic= s. The state of the art is: std::mutex mtx1, mtx2; ... std::lock_guard guard1(mtx1); std::lock_guard guard2(mtx2); // deadlocks if somebody els= e tries to lock mtx2 and then mtx1 or std::lock(mtx1, mtx2); // cannot deadlock, per [thread.lock.algorithm] // if anything here throws, we forget to unlock =E2=80=94 yikes! std::lock_guard guard1(mtx1, std::adopt_lock), guard2(mtx2,= std::adopt_lock); What I'd like to see is: std::lock_guard guard(mtx1, mtx2); // cannot deadlock and is exception-safe But what N4470 actually proposes is: std::lock_guard guard(mtx1, mtx2); // can still deadlock, because it fails to use [thread.lock.algorithm] = for the internals The repetition of "std::mutex, std::mutex" is ugly syntax. The potential for deadlock is ugly semantics. I haven't given the question too much thought, but perhaps all that's neede= d here is a "tuple of locks" concept. (std::apply borrowed from N3829.) template class lock_tuple { std::tuple mutexes; public: explicit lock_tuple(Mutex&... mtx) : mutexes(mtx...) {} void lock() { auto locker =3D [](auto&... mtx) { std::lock(mtx...); }; std::apply(locker, this->mutexes); } void unlock() { // doesn't really matter in what order we unlock them auto unlocker =3D [](auto&... mtx) { auto _ { ((void)mtx.unlock(), = 0)... }; }; std::apply(unlocker, this->mutexes); } }; template lock_tuple make_lock_tuple(Mutex&... mtx) { return lock_tuple(mtx...); } Then what we end up with is std::mutex mtx1, mtx2; ... auto both =3D make_lock_tuple(mtx1, mtx2); std::lock_guard guard(both); // exception-safe AND can= not deadlock This strikes me as a cleaner syntax AND cleaner semantics, AND can be imple= mented by adding one new class to the standard library instead of having to= replace an existing class. One reason not to adopt either of these proposals (neither N4470 nor lock_tuple) i= s that they're both coming from the POV of, "I use a lot of raw locking pri= mitives and I run into deadlock a lot, and I want to make deadlock less lik= ely." A very valid response would be, "Stop trying to use raw locking prim= itives, then!" "C++ makes it harder for you to shoot yourself in the foot, but when you do= , it blows your whole leg off." Any addition to , IMHO, has to prove that it's not simply contri= buting to the problem of C++ programmers blowing off their legs. my $.02, =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_9A3E0561DCF227429F72080EA81ADBC95084453ECATUS1XCHEVSPIN_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks for = your comments. =C2=A0Arthur,

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

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 types (like Howard=E2= =80=99s operator=3D example in the paper), and it just seems inaccurate to = do otherwise.

3.&n= bsp;      If N= 4471 is adopted, then you don=E2=80=99t need to worry about template argume= nts.
auto guard =3D lock_guard(mtx1, mtx2);

<= ![if !supportLists]>4.       Even without N4471, since all of the common use = cases we could think of involve 0, 1, or 2 mutexes (note that 0 locks is us= eful as well), the notational overhead isn=E2=80=99t excessive.<= /span>

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 argum= ents. (Since lock_guard is not movable, you can=E2=80=99t do this with lock= _guards).

6. &= nbsp;     While I s= ympathize with your desire to avoid raw locking primitives, I think the use= cases in the paper are appropriate and of course, explicit locks are commo= n in practices. C++ in general has the philosophy of offering both low-leve= l primitives and high-level abstractions. In any case, if we choose to prov= ide raw locking primitives, I think the relevant question is whether or not= they are better if variadic (also see #8 below).

       In particular, I think the built-in deadloc= k avoidance (Once the wording embarrassment from #1 above is fixed!) will r= esult in more reliable programs in practice, if only because many user-defi= ned types follow the rule of three=E2=80=99s imprecation to provide assignm= ent operators.

8.&n= bsp;      I=E2= =80=99m having trouble seeing any reason we shouldn=E2=80=99t allow lock_gu= ard to be variadic. The proposal is easy to ignore if you don=E2=80=99t lik= e 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 s= td::lock is more confusing because it was variadic.

 

What do you think,

&= nbsp;

Mike

<= p class=3DMsoNormal> 

<= b>From:= Arthur O'Dwyer [mailto:arthur.j.odwyer@gmail.com]
Sent: Thursda= y, April 30, 2015 5:14 AM
To: std-proposals@isocpp.org
Cc:<= /b> Michael Spertus
Subject: Comments on N4470 "Variadic loc= k_guard"

 

I was just reading Mike Spertus' N4470 &qu= ot;Variadic lock_guard":

= http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4470.html=

 

My first impression was, "Wow, this is a slam-dunk obvio= us proposal... of course lock_guard should be able to take multiple argumen= ts!"

But the further I r= ead, the uglier it seems, both in syntax and in semantics.

 

The state of the art is:

 

    std::mutex mtx1, mtx2;
    ...
    std::lock_guard<= std::mutex> guard1mtx1);
    std::lock_guard<std::mutex> guard2(mtx2); =  // deadlocks if somebody= else tries to lock mtx2 and then mtx1

=

 

o= r

 

=

    std::lock<= span class=3Dstyled-by-prettify>(m= tx1, mtx2);  // cannot deadlock, per [thread.lock.algorithm]    // if anything here throws, we forget to unlock =E2=80= =94 yikes!
    std<= /span>::lock_guard<std::mutex> guard1(<= span class=3Dstyled-by-prettify>mtx1 std::adopt_lock= ),(= mtx2, std::ad= opt_lock);

=

 

What I'd like to see is:

 

   = std::lock_guard&= lt;std::mutex> guard(mtx1, mtx2);
&= nbsp;   // cannot deadloc= k and is exception-safe

 

But what N4470 a= ctually proposes is:

&nb= sp;

    std::lo= ck_guard<std= ::= mutex, std= ::mutex> guard(mtx1, mtx2);
    // can still deadlock, because it fails to use [thread.lock.algorithm] for= the internals

 

The repetition of "<= span style=3D'font-family:"Courier New"'>std::mutex, std::mutex"= ; is ugly syntax.

The potenti= al for deadlock is ugly semantics.

 

I haven't given = the question too much thought, but perhaps all that's needed here is= a "tuple of locks" concept.

(std::apply borrowed from N3829.)

 

template<<= span class=3Dstyled-by-prettify>class... Mutex<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:#666600'>>= ;
class lock_tuple {
    std::tuple<<= /span>Mutex&...> mutexes= ;
  publi= c:
    explicit lock_tuple(Mutex&... mtx) : mutexes(mtx...) {}
    = void lock<= span class=3Dstyled-by-prettify>()= {
        locker =3D [](auto&... mtx= )= {::lock(mtx...);= };
        std::apply(locker, this->mutexes
    }
    void unlock() {
        // doesn't really matter in what order we unlock them
        auto u= nlocker =3D [](auto mtx) { <= span style=3D'font-size:10.0pt;font-family:"Courier New";color:#000088'>aut= o _ ((void)mtx.unlock(), 0)... }; <= /span>};
        std::apply(unlocker, this->mutexes);
    }
};

template<class... Mutex>lock_tuple<Mutex= ...> make_lock_tuple(= Mutex&...= mtx= ) {   return lock_= tuple(mtx...);
}

 

Then what we end up with is

 

   = std::mutex mtx1,= mtx2;
  =   ...
    auto both =3D make_lock_tuple(mtx1, mtx2<= span class=3Dstyled-by-prettify>);
    std::= lock_guard<decltype(both)><= /span> guard(both); =  // exception-safe AND ca= nnot deadlock


This strikes m= e as a cleaner syntax AND cleaner semantics, AND can be implemented by addi= ng one new class to the standard library instead of having to replace an ex= isting class.

 

One reason not to adopt either of the= se proposals (neither N4470 nor lock_tuple) is that they're both coming from the POV of, &quo= t;I use a lot of raw locking primitives and I run into deadlock a lot, and = I want to make deadlock less likely."  A very valid response woul= d be, "Stop trying to use raw locking primitives, then!"

 

&q= uot;C++ makes it harder for you to shoot yourself in the foot, but when you= do, it blows your whole leg off."  Any addition to <mutex>, IMHO, has to prove t= hat it's not simply contributing to the problem of C++ programmers blowing = off their legs.

 

my $.02,

<= p class=3DMsoNormal>=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_9A3E0561DCF227429F72080EA81ADBC95084453ECATUS1XCHEVSPIN_-- .