220 26884 article Path: news.gmane.org!not-for-mail From: Arthur O'Dwyer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: std::lock and std::lock_guard for SharedLockable's lock_shared Date: Tue, 12 Jul 2016 22:55:48 -0700 (PDT) Lines: 193 Approved: news@gmane.org Message-ID: References: <8d4cc002-f0f2-465f-b856-841adc1ecffd@isocpp.org> <2DCF8C2C-C662-49EE-B7E5-3FA11B47AB58@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_566_1377096605.1468389348938" X-Trace: ger.gmane.org 1468389361 21102 80.91.229.3 (13 Jul 2016 05:56:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Jul 2016 05:56:01 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDLZJYWNDQIOLL4XXQCRUBAEUQCCI@isocpp.org Wed Jul 13 07:55:52 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f199.google.com ([209.85.220.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bND9D-0003aV-Vw for gclcip-std-proposals@m.gmane.org; Wed, 13 Jul 2016 07:55:52 +0200 Original-Received: by mail-qk0-f199.google.com with SMTP id f7sf68461441qkc.0 for ; Tue, 12 Jul 2016 22:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=MPcLDmG0bnDfwmIp9fjR4PwOJXIBhgX9lcCWa3weLps=; b=BvNaoj7i3GZLpotEmGbYqhaWZ58Vd/Nud1XA/7QHNTRQChKllFY6Vhu+k2lT6U+lgk fCJxCeyXSFY3S2qmL3MdgNWF+d6hNlw24ZEd/GddZc5VE13PgNxxjCubHSoWuJa2RdyY w/qi9XeBMdkuBLaTnhEsKdboomrV/unqLZnptYhBx1vpjcJRBYNnaIpGa+A6QgyxZCNF ebUz1zwNUHyxyu6uqVah9xhsCg8nMUVaVqWRah6WLMYWU7652ByUXz+PlQ6nerACU7K4 La8nUtX3NOM8hGijRRnxZRVn7xY84aL34elHkry2Sc6ZzvIErXADF0BUWvCY7Yte2oX1 KqCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=MPcLDmG0bnDfwmIp9fjR4PwOJXIBhgX9lcCWa3weLps=; b=sNH0aBVKriOaN2HPndTEmJCM6wk1RPJlP1Xnl9raNHGxcFzhvK87F2iADQ1n3veiUz 88ci3gp5ccbCOVUFm+uzHNJCfpH0ahe7IXFILXlRYYFjH+Z5S3kGNVw3kVBfhFLKtmPv trWL8vi+tUPJYMWR2f8QhmJaWPhVmO9m4K6H01VClqnEfSXfkOjJOsbrBWeY7g3nz4Y9 v6oy6SI3ekAvSvd8ioIc6yWncHbKZs2bnI40sPkEOtMZf7jsHD99ndNsLs5ckxF+wxCh buerBlSaVAuo2wYZc2tWrhGC8B+p45Xu3AHc4vWwwxPzh4Lahy6GwRH/0jUb1GMhDmX3 t0Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=MPcLDmG0bnDfwmIp9fjR4PwOJXIBhgX9lcCWa3weLps=; b=dZM//6Vk8HNBt1378DsqaCFJsrSNb3T1c8AT3jwYljjDzylLZxDlqsdgZUA2MsKBBp MlmpcJ54CYsOfSMU3ZwW8f3GeWLZ9qXU2ai74oH/zPBbhl4T1INWS97cbD1C2YcdYDbH fM0oKSj83OBN7LG1p9FF4otzMwSMXs8LYMBWR5CKBXNc0h3toYLgbxWkyLRh/6iOIvMV tEXHnO7rD2dupGAVTGLveuZCSvc3Fe0V4HFWJ168xXBgyJ2ntslMTrKZopa9D+4+KlY8 goBN8naAwYCIm2wLNQHT92CPxt89vPClJ2U76zbE/9UZLma9eA78eCQG9n/l6vICebjp 6MOg== X-Gm-Message-State: ALyK8tLmwB9i+3NRq46ziiCc9RICoBpugR/4LAW29+08/W8vIJhVlzZn9KJhvSNR1iMZmA== X-Received: by 10.129.164.88 with SMTP id b85mr4834810ywh.37.1468389351069; Tue, 12 Jul 2016 22:55:51 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.169.6 with SMTP id s6ls496412ioe.53.gmail; Tue, 12 Jul 2016 22:55:49 -0700 (PDT) X-Received: by 10.36.133.10 with SMTP id r10mr258937itd.1.1468389349676; Tue, 12 Jul 2016 22:55:49 -0700 (PDT) In-Reply-To: <2DCF8C2C-C662-49EE-B7E5-3FA11B47AB58@gmail.com> X-Original-Sender: arthur.j.odwyer@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:26884 Archived-At: ------=_Part_566_1377096605.1468389348938 Content-Type: multipart/alternative; boundary="----=_Part_567_727435535.1468389348938" ------=_Part_567_727435535.1468389348938 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, July 12, 2016 at 12:34:38 PM UTC-7, Howard Hinnant wrote: > > On Jul 12, 2016, at 3:09 PM, 'Bernd' via ISO C++ Standard - Future=20 > Proposals > wrote:=20 > >=20 > > In discussions on Andrei's NDC talk about folly/Synchronized [1] the=20 > question came up why his deadlock prevention [2] did not just use=20 > std::lock(). It was pointed out that this is due to using=20 > SharedLockable::lock_shared(), making std::lock() the wrong thing. [...] > > I propose adding std::lock_shared (SharedLockable&...) > [...]=20 > > On the same note, C++17 added std::lock_guard, which has n= o=20 > SharedLockable variant either [...] > > I can assure you it wasn=E2=80=99t an oversight. And your first =E2=80= =9Cworkaround=E2=80=9D is=20 > the intended use.=20 > > We don=E2=80=99t need or want a =E2=80=9Ckitchen sink=E2=80=9D API where = there are 3 three=20 > different ways to do everything. We already have that with std::string,= =20 > and we don=E2=80=99t need to repeat that design mistake.=20 > As someone who wasn't involved at all in the design process for=20 lock/shared_lock/lock_guard, let me add another reason NOT to add more lock= =20 variants than we already have: massive confusion for newbies. When I first learned about std::mutex and std::lock_guard, I thought it was= =20 the neatest thing ever. Then I learned about std::unique_lock, which was even neater =E2=80=94 it w= as like=20 lock_guard, but you could actually pass it around from place to place. Mind= =20 you, you couldn't *copy* it =E2=80=94 it was a move-only type =E2=80=94 thi= s was obviously=20 why they called it *unique*_lock, just like C++11's other move-only type,= =20 *unique*_ptr. Then came shared_mutex. Which kind of makes sense as a name... kind of. I= =20 mean, anyone who's taken Operating Systems in university knows that what it= =20 really is is a reader-writer lock=20 , a.k.a. r=20 w=20 lo=20 c=20 k=20 , but okay,= =20 the Committee hates acronyms or something, so yeah, it does behave kind of= =20 like a mutex that you can "share". And so it has a method lock_shared().= =20 Makes sense if you think about it. And then... wait a minute. Was my intuition about unique_lock wrong? Did it= =20 actually get its name not because it's move-only, but because it takes an= =20 *exclusive* lock on the mutex it controls? (Seeing the Committee fumble=20 the noun "rwlock" leads to the horrible thought that they might equally=20 have fumbled the adjective "exclusive".) So then what's a *shared*_lock?= =20 ....which showed up in C++14, as a move-only type! This way lies madness.=20 Best to just sweep it under the bed and try to forget about it. I welcome anything the Committee can do at this point to limit the=20 confusion and preserve the general principle of "*unique_* things are=20 move-only, *shared_* things are copyable, and things pretty much do what=20 they say on the tin (except for shared_mutex which is really rwlock in=20 disguise, oops)" =E2=80=94 which means I would attempt to oppose the additi= on of=20 any new *shared_* stuff to the library unless it really clearly did what it= =20 appeared to say on the tin. =E2=80=93Arthur --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/cd6a8704-4358-4698-85ba-05dd65396190%40isocpp.or= g. ------=_Part_567_727435535.1468389348938 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tuesday, July 12, 2016 at 12:34:38 PM UTC-7, Howard Hin= nant wrote:
On Jul 12, 2016, at= 3:09 PM, 'Bernd' via ISO C++ Standard - Future Proposals <std-pr...@= isocpp.org> wrote:
>=20
> In discussions on Andrei's NDC talk about folly/Synchronized [= 1] the question came up why his deadlock prevention [2] did not just use st= d::lock(). It was pointed out that this is due to using SharedLockable::loc= k_shared(), making std::lock() the wrong thing. [...]
> I propose add= ing std::lock_shared (SharedLockable&...)
[...]=C2= =A0
> On the same note= , C++17 added std::lock_guard<Lockable...>, which has no SharedLockab= le variant either [...]

I can assure you it wasn=E2=80=99t an oversight. =C2=A0And your first = =E2=80=9Cworkaround=E2=80=9D is the intended use.

We don=E2=80=99t need or want a =E2=80=9Ckitchen sink=E2=80=9D API wher= e there are 3 three different ways to do everything. =C2=A0We already have = that with std::string, and we don=E2=80=99t need to repeat that design mist= ake.

As someone who wasn't involved at = all in the design process for lock/shared_lock/lock_guard, let me add anoth= er reason NOT to add more lock variants than we already have: massive confu= sion for newbies.

When I first learned about std::= mutex and std::lock_guard, I thought it was the neatest thing ever.
Then I learned about std::unique_lock, which was even neater =E2=80=94 i= t was like lock_guard, but you could actually pass it around from place to = place. Mind you, you couldn't copy it =E2=80=94 it was a = move-only type =E2=80=94 this was obviously why they called it unique= _lock, just like C++11's other move-only type, unique= _ptr.

Then came shared_mutex. Which kind of ma= kes sense as a name... kind of. I mean, anyone who's taken Operating Sy= stems in university knows that what it really is is a reader-writer lock, a.= k.a. rwlock, but okay, the Co= mmittee hates acronyms or something, so yeah, it does behave kind of like a= mutex that you can "share". =C2=A0And so it has a method lock_sh= ared(). =C2=A0Makes sense if you think about it.

A= nd then... wait a minute. Was my intuition about unique_lock wrong? Did it = actually get its name not because it's move-only, but because it takes = an exclusive lock on the mutex it controls? =C2=A0(Seeing the= Committee fumble the noun "rwlock" leads to the horrible thought= that they might equally have fumbled=C2=A0the adjective "exclusive&qu= ot;.) =C2=A0So then what's a shared_lock? ...which showed up in = C++14, as a move-only type! This way lies madness. Best to just sweep it un= der the bed and try to forget about it.

I welcome = anything the Committee can do at this point to limit the confusion and pres= erve the general principle of "unique_=C2=A0things are move-onl= y, shared_=C2=A0things are copyable, and things pretty much do what = they say on the tin (except for shared_mutex which is really rwlock in disg= uise, oops)" =E2=80=94 which means I would attempt to oppose the addit= ion of any new shared_ stuff to the library unless it really clearly= did what it appeared to say on the tin.

=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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/cd6a8704-4358-4698-85ba-05dd65396190= %40isocpp.org.
------=_Part_567_727435535.1468389348938-- ------=_Part_566_1377096605.1468389348938-- .