------=_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
<https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/tQb9t6Hnu6M>
..

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

<div dir=3D"ltr">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:<div><br></div><div=
><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); =
word-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><div class=3D"subprettyprint=
">_GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE(&amp;_M_weak_count);</div><div cl=
ass=3D"subprettyprint">if (__gnu_cxx::__exchange_and_add_dispatch(&amp;_M_w=
eak_count, -1) =3D=3D 1) {</div><div class=3D"subprettyprint">=C2=A0 _GLIBC=
XX_SYNCHRONIZATION_HAPPENS_AFTER(&amp;_M_weak_count);</div><div class=3D"su=
bprettyprint">=C2=A0 _M_destroy();</div><div class=3D"subprettyprint">}</di=
v></div></code></div><br>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 <a href=3D"https://groups.google.com/a/isocpp.org/forum/#=
!topic/std-proposals/tQb9t6Hnu6M">structural support</a>.</div><div><br></d=
iv><div>Is there any use case I missed for this issue? I am looking forward=
 to your comments!</div><div><br></div><div>Thank you!</div><div><br></div>=
<div>Mingxin Wang</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/10c6dcad-6b2f-484b-a618-943867d7498c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/10c6dcad-6b2f-484b-a618-943867d7498c=
%40isocpp.org</a>.<br />

------=_Part_1365_1207181568.1498361723524--

------=_Part_1364_1645611440.1498361723524--

.

------=_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

<div dir=3D"ltr">On Saturday, June 24, 2017 at 11:35:23 PM UTC-4, Mingxin W=
ang wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">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></blockquote><div><br>If you&#39;re referring to the semantics of the =
atomic decrement, I&#39;m fairly sure that&#39;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.<br><b=
r>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=
 &quot;happens before&quot; the object being destroyed.<br><br>But what if =
it <i>wasn&#39;t</i> 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 &quot;happen before&quot; the destructor being calle=
d in Thread 2.<br><br>So I would say that the acquire/release is not option=
al.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/87997583-62ae-40c9-a58f-9ddbd3cdf099%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/87997583-62ae-40c9-a58f-9ddbd3cdf099=
%40isocpp.org</a>.<br />

------=_Part_1340_1390481323.1498363285704--

------=_Part_1339_529634643.1498363285703--

.