220 32870 <87997583-62ae-40c9-a58f-9ddbd3cdf099@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Could the memory order be relaxed in the implementation of std::shared_ptr? Date: Sat, 24 Jun 2017 21:01:25 -0700 (PDT) Lines: 82 Approved: news@gmane.org Message-ID: <87997583-62ae-40c9-a58f-9ddbd3cdf099@isocpp.org> References: <10c6dcad-6b2f-484b-a618-943867d7498c@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1339_529634643.1498363285703" X-Trace: blaine.gmane.org 1498363287 27596 195.159.176.226 (25 Jun 2017 04:01:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 25 Jun 2017 04:01:27 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBFXLXTFAKGQEAQKJ7YI@isocpp.org Sun Jun 25 06:01:23 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f198.google.com ([209.85.192.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dOyji-0006tU-3t for gclcip-std-proposals@m.gmane.org; Sun, 25 Jun 2017 06:01:22 +0200 Original-Received: by mail-pf0-f198.google.com with SMTP id y62sf77658468pfa.3 for ; Sat, 24 Jun 2017 21:01:27 -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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=KHMsyQxuP5s1hc/S69vHO5Yq0ymsJTvBmWWIxFIGW2k=; b=ZkIg5ZVHLM7yw3f25B3XuLAPi+P/+9mynyUKspNJD5ZK8oIhcn1tDqyZRpfnz0fIsF XBDDE311BVU+nXAjY9uE+TwFqMh/aCWYnsofUeiyvVy5vO+P8WZi58bm8A4plYY7AvUT n/U37whGbTRatKGpW6AqZFfvqYzRpsAjvKLbEB5LN77fiVS0Wj5p6Hxsl5SqfrhpL75I OTa6Wh1tCaSNG+4L9PVGwv4Crymq0o7a7j+KeCJ544ChRmQ27qKBhCIvziTO1NqAs45F RJS3Ac0HKbhahs1OCcrmXBVOrFsLm/m9hy+/d2yitxU7zUWgQ/VILZ4IAMBdsGo3x+kk pB9g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=KHMsyQxuP5s1hc/S69vHO5Yq0ymsJTvBmWWIxFIGW2k=; b=KjyvtCID72MuUhR/A7IPHqeZO3IEINBlzY4j4BiG1tTlFNRRPRp9ANBRXtaVP0OieL OguiZFjwUN5m8jqNDYQAlVYVFriNPCBLUGAJGMD+rj1Z84dggXvqkRNJ4+4InfUUFniq H22/B6bVbgHh1NisQ6RUCZ8w8xDkQLpNbaZUkaYWM96p3aEiVzx+A2J0ZAyxLHu58rSg AwJvj4UwOMkKzWGxiPPI00h4F3PzhS9gc+oEE173AA9DGvC5XJpOkHTuIDQ3Mxw8Mu6V VkkfhhT52W4G4vtn5TU+pl15vGfeG45c/C0syGJdHA6/aaqfoO1NX9j7P6ucjBATMq6D OlYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=KHMsyQxuP5s1hc/S69vHO5Yq0ymsJTvBmWWIxFIGW2k=; b=ankcKagaomZgFtn+Po8xTZRbsA2YJvbdcmrbabwEVmhfHZ9J4DaKDs1gzWgusTVgVv 4Yge7D4CZICbM9kI6B6sItc/mLO7T3eQ9kpUM2iYA1yeBKu3cmc3ATIkcdy4SqOW9ptB 2EQcZ8QuWaRVsvuwcwxcAOKwcnNXJg5Ged6MpgpzN+wlu8Qc4ErdgPolpkUa2acMB1m7 O9swgEQ2Pl46X8yLhdUj546iZnWyMAzwtNY7YkKltsI750WyCOUjPGP5LsF/SWYGOJe9 mYw8MHPgYV8nhe8XZ8ZTlvK38Ifzcvump2WzuvavBxzdNTr5Mu4VZE/z6f6HSZAyn8hR kIhw== X-Gm-Message-State: AKS2vOyO/Uxv8KSWBaUfFwBw6SZ/trxgOgxpAkau2+TvQoiTOnn3PN0z VIyv63WpXy2YyQnx X-Received: by 10.99.126.8 with SMTP id z8mr8933636pgc.130.1498363287092; Sat, 24 Jun 2017 21:01:27 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.48.211 with SMTP id r19ls6458321otg.14.gmail; Sat, 24 Jun 2017 21:01:26 -0700 (PDT) X-Received: by 10.157.46.80 with SMTP id c16mr370297otd.7.1498363286243; Sat, 24 Jun 2017 21:01:26 -0700 (PDT) In-Reply-To: <10c6dcad-6b2f-484b-a618-943867d7498c@isocpp.org> X-Original-Sender: jmckesson@gmail.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:32870 Archived-At: ------=_Part_1339_529634643.1498363285703 Content-Type: multipart/alternative; boundary="----=_Part_1340_1390481323.1498363285704" ------=_Part_1340_1390481323.1498363285704 Content-Type: text/plain; charset="UTF-8" On Saturday, June 24, 2017 at 11:35:23 PM UTC-4, Mingxin Wang wrote: > > After analysing the implementation of std::shared_ptr in GCC (6.3), I > found there is a synchronization in its destructor (not required in the > standard), > If you're referring to the semantics of the atomic decrement, I'm fairly sure that's required by the standard. Without that acquire/release increment, consider what happens if two shared_ptrs to the same object are being destroyed on two separate threads. Thread 1 sets some non-atomic state, then destroys its `shared_ptr`. If that `shared_ptr` is the last pointer, then the destructor will be able to see the non-atomic state that was set, since the destructor will run on this thread. So logically, Thread 1 is saying that the non-atomic state setting "happens before" the object being destroyed. But what if it *wasn't* the last pointer? The last pointer is on Thread 2, which destroys the object later. Without the acquire/release, none of those changes on Thread 1 will "happen before" the destructor being called in Thread 2. So I would say that the acquire/release is not optional. -- 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 email 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/87997583-62ae-40c9-a58f-9ddbd3cdf099%40isocpp.org. ------=_Part_1340_1390481323.1498363285704 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Saturday, June 24, 2017 at 11:35:23 PM UTC-4, Mingxin W= ang wrote:
Aft= er analysing the implementation of std::shared_ptr in GCC (6.3), I found th= ere is a synchronization in its destructor (not required in the standard),<= /div>

If you're referring to the semantics of the = atomic decrement, I'm fairly sure that's required by the standard. = Without that acquire/release increment, consider what happens if two shared= _ptrs to the same object are being destroyed on two separate threads.
Thread 1 sets some non-atomic state, then destroys its `shared_ptr`. If t= hat `shared_ptr` is the last pointer, then the destructor will be able to s= ee the non-atomic state that was set, since the destructor will run on this= thread. So logically, Thread 1 is saying that the non-atomic state setting= "happens before" the object being destroyed.

But what if = it wasn't the last pointer? The last pointer is on Thread 2, whi= ch destroys the object later. Without the acquire/release, none of those ch= anges on Thread 1 will "happen before" the destructor being calle= d in Thread 2.

So I would say that the acquire/release is not option= al.

--
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/87997583-62ae-40c9-a58f-9ddbd3cdf099= %40isocpp.org.
------=_Part_1340_1390481323.1498363285704-- ------=_Part_1339_529634643.1498363285703-- .