220 32868 <10c6dcad-6b2f-484b-a618-943867d7498c@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Mingxin Wang Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Could the memory order be relaxed in the implementation of std::shared_ptr? Date: Sat, 24 Jun 2017 20:35:23 -0700 (PDT) Lines: 83 Approved: news@gmane.org Message-ID: <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_1364_1645611440.1498361723524" X-Trace: blaine.gmane.org 1498361726 18842 195.159.176.226 (25 Jun 2017 03:35:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 25 Jun 2017 03:35:26 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDNMBNHJWIGBB7G6XTFAKGQEKZXRTJY@isocpp.org Sun Jun 25 05:35:21 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f197.google.com ([209.85.223.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dOyKW-0004dH-Cl for gclcip-std-proposals@m.gmane.org; Sun, 25 Jun 2017 05:35:20 +0200 Original-Received: by mail-io0-f197.google.com with SMTP id p138sf69122676ioe.13 for ; Sat, 24 Jun 2017 20:35:25 -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:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=nUYSAp0IzEua11Yfpr8mJNWAJBdpnjVo1jk7OlY160I=; b=inhdIYR2ruVJHX2Uw2/xrGuv/+asJzyVjrGI61Fx+a2XAn4fvo24mGijd8WVAV8hDx /lsinsJfBBaFHK2vbdUHTe5VLs6K3aTXKr1nZcZv5ZQqVwKQ7THmiwZbGytdWIgP5f3G 9KkyBwITSQY67X5bUQRi5VTBeod+UZO5dwfifQKnppQsC51Qn5sqsUano1RVG0uQAA40 H57aZ+xXN9lxXaGMKovCN8CL+MKTApIIuOx8A8jVsCTKN46ekkAIxq+Dp/R+CX8HaZPr VTLLOeRupX37XzqrCbca2iT+RR+M6/tg9embOxLvzBpH13qEfDfzmCTYdweNdLtZjaM4 Lh+w== 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: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=nUYSAp0IzEua11Yfpr8mJNWAJBdpnjVo1jk7OlY160I=; b=BvrNB6CdPcSkJCbcB2Mt33hBDvMFGoykkgfG+IXik1glihvql/h2KvHBLNuYDzqsBJ LxkV+73hpX6r0mowyYLiK5U5Vea9S+64MfHwf23Rv9ig+aQMhcekwZcYe7KJhr85J09w J1wcQNJpF4bTqxClC/TnJy7p2Ti4S5Rpf0eTxNDiRWoWcnZYSfa4VmMxNOjYPm4VfBnb duAc6bq5PRyWNZ8dnl8Bui15m4NZ6kEGlXMBtWHqH5ysiM6Z7ZJ3oPWaCW4jHLzlwRK/ Rhf15oc42HW7txxDQzedy7G2sWcgwHAfaSi9CaDZmiciCJYJgF4VPTuGepn7SHNUFbEa bkyw== X-Gm-Message-State: AKS2vOyNwTiqLyCbhrSGqp39S8RI3uotCnDN8YLsxOcbxdiq6iR/QQW4 wI/JNfXQWimgnatu X-Received: by 10.107.34.194 with SMTP id i185mr8262949ioi.96.1498361724936; Sat, 24 Jun 2017 20:35:24 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.80.134 with SMTP id b6ls3114263oth.37.gmail; Sat, 24 Jun 2017 20:35:24 -0700 (PDT) X-Received: by 10.157.46.132 with SMTP id w4mr368698ota.18.1498361723991; Sat, 24 Jun 2017 20:35:23 -0700 (PDT) X-Original-Sender: wmx16835vv@163.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:32868 Archived-At: ------=_Part_1364_1645611440.1498361723524 Content-Type: multipart/alternative; boundary="----=_Part_1365_1207181568.1498361723524" ------=_Part_1365_1207181568.1498361723524 Content-Type: text/plain; charset="UTF-8" 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), which is an acquire-release one (a release sequence synchronizes with an acquire operation), as is shown below: _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE(&_M_weak_count); if (__gnu_cxx::__exchange_and_add_dispatch(&_M_weak_count, -1) == 1) { _GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER(&_M_weak_count); _M_destroy(); } In my daily use, I found this synchronization is not necessary most of the time, because there are usually other synchronization operations with more definite intentions in our client code, especially with proper structural support .. Is there any use case I missed for this issue? I am looking forward to your comments! Thank you! Mingxin Wang -- 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/10c6dcad-6b2f-484b-a618-943867d7498c%40isocpp.org. ------=_Part_1365_1207181568.1498361723524 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
After analysing the implementation of std::shared_ptr in G= CC (6.3), I found there is a synchronization in its destructor (not require= d in the standard), which is an acquire-release one (a release sequence syn= chronizes with an acquire operation), as is shown below:

_GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE(&_M_weak_count);
if (__gnu_cxx::__exchange_and_add_dispatch(&_M_w= eak_count, -1) =3D=3D 1) {
=C2=A0 _GLIBC= XX_SYNCHRONIZATION_HAPPENS_AFTER(&_M_weak_count);
=C2=A0 _M_destroy();
}

In my daily use, I found this synchronization is n= ot necessary most of the time, because there are usually other synchronizat= ion operations with more definite intentions=C2=A0in our client code, espec= ially with proper structural support.

Is there any use case I missed for this issue? I am looking forward= to your comments!

Thank you!

=
Mingxin Wang

--
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/10c6dcad-6b2f-484b-a618-943867d7498c= %40isocpp.org.
------=_Part_1365_1207181568.1498361723524-- ------=_Part_1364_1645611440.1498361723524-- .