Topic: For atomic<T> instances, is there a need for a


Author: Brian Bi <bbi5291@gmail.com>
Date: Sun, 14 Aug 2016 08:11:30 +0800
Raw View
--001a1142c240260ed20539fcf5e9
Content-Type: text/plain; charset=UTF-8

I don't think the standard ever says how many times a variable is supposed
to be loaded, unless it's volatile. It's not part of the observable
behavior of the program.

On Sun, Aug 14, 2016 at 7:55 AM, 'Walt Karas' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:

> For the code:
>
> atomic<int> i;
> int sum = i.load(memory_order_relaxed);
> sum += i.load(memory_order_relaxed);
>
> both clang and gcc will load i from memory twice.  Was this the intent of
> the Standard?
>
> If an atomic instance is only ever written in a single thread, then loads
> in that thread can correctly be optimized out I think.  Do we need another
> memory order (memory_order_none perhaps) to indicate loads of the instance
> from memory are not necessary if the value of it is still in register(s)
> (due to a preceding load or store)?
>
> --
> 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/51b50bc6-941e-4c52-
> b124-6a0e98838a45%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/51b50bc6-941e-4c52-b124-6a0e98838a45%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>



--
*Brian Bi*

--
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/CAMmfjbMmYot7nZ-tS4pQrN8cWpgsOrCBMKtjRgWcJAUYnvHifg%40mail.gmail.com.

--001a1142c240260ed20539fcf5e9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I don&#39;t think the standard ever says how many times a =
variable is supposed to be loaded, unless it&#39;s volatile. It&#39;s not p=
art of the observable behavior of the program.<br></div><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote">On Sun, Aug 14, 2016 at 7:55 AM, &#3=
9;Walt Karas&#39; via ISO C++ Standard - Future Proposals <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-prop=
osals@isocpp.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr">For the code:<div><br></div><div>atomic&lt;int&gt; i;</div><=
div>int sum =3D i.load(memory_order_relaxed);</div><div>sum +=3D i.load(mem=
ory_order_relaxed);</div><div><br></div><div>both clang and gcc will load i=
 from memory twice.=C2=A0 Was this the intent of the Standard?</div><div><b=
r></div><div>If an atomic instance is only ever written in a single thread,=
 then loads in that thread can correctly be optimized out I think.=C2=A0 Do=
 we need another memory order (memory_order_none perhaps) to indicate loads=
 of the instance from memory are not necessary if the value of it is still =
in register(s) (due to a preceding load or store)?</div></div><span class=
=3D"HOEnZb"><font color=3D"#888888">

<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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/51b50bc6-941e-4c52-b124-6a0e98838a45%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/51b5=
0bc6-941e-4c52-<wbr>b124-6a0e98838a45%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div clas=
s=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><=
div><div dir=3D"ltr"><font color=3D"#c0c0c0"><i>Brian Bi</i></font><br><div=
></div><div></div><div></div></div></div></div></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/CAMmfjbMmYot7nZ-tS4pQrN8cWpgsOrCBMKtj=
RgWcJAUYnvHifg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbMmYot7nZ-t=
S4pQrN8cWpgsOrCBMKtjRgWcJAUYnvHifg%40mail.gmail.com</a>.<br />

--001a1142c240260ed20539fcf5e9--

.


Author: Tony V E <tvaneerd@gmail.com>
Date: Sat, 13 Aug 2016 21:38:20 -0400
Raw View
--001a11442a6ab59cf80539fe2b96
Content-Type: text/plain; charset=UTF-8

On Sat, Aug 13, 2016 at 7:55 PM, 'Walt Karas' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:

> For the code:
>
> atomic<int> i;
> int sum = i.load(memory_order_relaxed);
> sum += i.load(memory_order_relaxed);
>
> both clang and gcc will load i from memory twice.  Was this the intent of
> the Standard?
>
> If an atomic instance is only ever written in a single thread, then loads
> in that thread can correctly be optimized out I think.  Do we need another
> memory order (memory_order_none perhaps) to indicate loads of the instance
> from memory are not necessary if the value of it is still in register(s)
> (due to a preceding load or store)?
>
> --
> 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/51b50bc6-941e-4c52-
> b124-6a0e98838a45%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/51b50bc6-941e-4c52-b124-6a0e98838a45%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>


"No Sane Compiler Would Optimize Atomics"
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4455.html


Abstract: False.


This looks like something a compiler could (soon?) optimize.


--
Be seeing you,
Tony

--
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/CAOHCbiuM%3DVKyzMfD3nbRJiTb7j_Eyr%3DkMHmeTahZHPUc7zPGzg%40mail.gmail.com.

--001a11442a6ab59cf80539fe2b96
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Aug 13, 2016 at 7:55 PM, &#39;Walt Karas&#39; via ISO C++ Standard - Fu=
ture Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">For the c=
ode:<div><br></div><div>atomic&lt;int&gt; i;</div><div>int sum =3D i.load(m=
emory_order_relaxed);</div><div>sum +=3D i.load(memory_order_relaxed);</div=
><div><br></div><div>both clang and gcc will load i from memory twice.=C2=
=A0 Was this the intent of the Standard?</div><div><br></div><div>If an ato=
mic instance is only ever written in a single thread, then loads in that th=
read can correctly be optimized out I think.=C2=A0 Do we need another memor=
y order (memory_order_none perhaps) to indicate loads of the instance from =
memory are not necessary if the value of it is still in register(s) (due to=
 a preceding load or store)?</div></div><span class=3D""><font color=3D"#88=
8888">

<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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/51b50bc6-941e-4c52-b124-6a0e98838a45%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/51b5=
0bc6-941e-4c52-<wbr>b124-6a0e98838a45%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><div>&quot;No S=
ane Compiler Would Optimize Atomics&quot;<br><a href=3D"http://www.open-std=
..org/jtc1/sc22/wg21/docs/papers/2015/n4455.html">http://www.open-std.org/jt=
c1/sc22/wg21/docs/papers/2015/n4455.html</a><br></div><br><br>Abstract: Fal=
se.<br><br><br></div>This looks like something a compiler could (soon?) opt=
imize.<br><br><br>-- <br><div class=3D"gmail_signature" data-smartmail=3D"g=
mail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div=
></div>
</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/CAOHCbiuM%3DVKyzMfD3nbRJiTb7j_Eyr%3Dk=
MHmeTahZHPUc7zPGzg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuM%3DV=
KyzMfD3nbRJiTb7j_Eyr%3DkMHmeTahZHPUc7zPGzg%40mail.gmail.com</a>.<br />

--001a11442a6ab59cf80539fe2b96--

.


Author: "'Walt Karas' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Sat, 13 Aug 2016 20:42:17 -0700 (PDT)
Raw View
------=_Part_2891_1452109025.1471146137834
Content-Type: multipart/alternative;
 boundary="----=_Part_2892_1078807022.1471146137835"

------=_Part_2892_1078807022.1471146137835
Content-Type: text/plain; charset=UTF-8

On Saturday, August 13, 2016 at 9:38:23 PM UTC-4, Tony V E wrote:
>
> On Sat, Aug 13, 2016 at 7:55 PM, 'Walt Karas' via ISO C++ Standard -
> Future Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>
>> For the code:
>>
>> atomic<int> i;
>> int sum = i.load(memory_order_relaxed);
>> sum += i.load(memory_order_relaxed);
>>
>> both clang and gcc will load i from memory twice.  Was this the intent of
>> the Standard?
>>
>> If an atomic instance is only ever written in a single thread, then loads
>> in that thread can correctly be optimized out I think.  Do we need another
>> memory order (memory_order_none perhaps) to indicate loads of the instance
>> from memory are not necessary if the value of it is still in register(s)
>> (due to a preceding load or store)?
>>
>> --
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/51b50bc6-941e-4c52-b124-6a0e98838a45%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/51b50bc6-941e-4c52-b124-6a0e98838a45%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> "No Sane Compiler Would Optimize Atomics"
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4455.html
>
>
> Abstract: False.
>
>
> This looks like something a compiler could (soon?) optimize.
>

I'm wondering if, given that this is not currently optimized, I should do
something like:

alignas(atomic<int>) int i;
static_assert((ATOMIC_INT_LOCK_FREE == 2) and (sizeof(atomic<int>) ==
sizeof(int)), "int not naturally atomic");

and use calls to atomic_thread_fence() for memory access ordering
requirements.

--
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/478d759b-2754-462a-b0d4-ac1ac99a84d7%40isocpp.org.

------=_Part_2892_1078807022.1471146137835
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, August 13, 2016 at 9:38:23 PM UTC-4, Tony V E=
 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"><div><=
div class=3D"gmail_quote">On Sat, Aug 13, 2016 at 7:55 PM, &#39;Walt Karas&=
#39; via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"9rQFCUGACgAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">std-pr...@is=
ocpp.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr">For the code:<div><br></div><div>atomic&lt;int&=
gt; i;</div><div>int sum =3D i.load(memory_order_relaxed);</div><div>sum +=
=3D i.load(memory_order_relaxed);</div><div><br></div><div>both clang and g=
cc will load i from memory twice.=C2=A0 Was this the intent of the Standard=
?</div><div><br></div><div>If an atomic instance is only ever written in a =
single thread, then loads in that thread can correctly be optimized out I t=
hink.=C2=A0 Do we need another memory order (memory_order_none perhaps) to =
indicate loads of the instance from memory are not necessary if the value o=
f it is still in register(s) (due to a preceding load or store)?</div></div=
><span><font color=3D"#888888">

<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
9rQFCUGACgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"9rQFCUGACgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@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/51b50bc6-941e-4c52-b124-6a0e98838a45%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/51b50bc6-941e-4c52-b124-6a0e98838a45%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/51b50bc6-941e-4c52-b124-6a0e98838a45%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/51b50bc6-941e-4c52-<wbr>b124-=
6a0e98838a45%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><div>&quot;No S=
ane Compiler Would Optimize Atomics&quot;<br><a href=3D"http://www.open-std=
..org/jtc1/sc22/wg21/docs/papers/2015/n4455.html" target=3D"_blank" rel=3D"n=
ofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhtt=
p%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fn4=
455.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHOMlCoFSJrf58FEzmesPY1HOBq=
rQ&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url=
?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F=
2015%2Fn4455.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHOMlCoFSJrf58FEzm=
esPY1HOBqrQ&#39;;return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/=
docs/papers/2015/<wbr>n4455.html</a><br></div><br><br>Abstract: False.<br><=
br><br></div>This looks like something a compiler could (soon?) optimize.</=
div></div></blockquote><div><br></div><div>I&#39;m wondering if, given that=
 this is not currently optimized, I should do something like:</div><div><br=
></div><div>alignas(atomic&lt;int&gt;) int i;</div><div>static_assert((ATOM=
IC_INT_LOCK_FREE =3D=3D 2) and (sizeof(atomic&lt;int&gt;) =3D=3D sizeof(int=
)), &quot;int not naturally atomic&quot;);<br></div><div><br></div><div>and=
 use calls to atomic_thread_fence() for memory access ordering requirements=
..</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/478d759b-2754-462a-b0d4-ac1ac99a84d7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/478d759b-2754-462a-b0d4-ac1ac99a84d7=
%40isocpp.org</a>.<br />

------=_Part_2892_1078807022.1471146137835--

------=_Part_2891_1452109025.1471146137834--

.


Author: Tony V E <tvaneerd@gmail.com>
Date: Sun, 14 Aug 2016 02:08:47 -0400
Raw View
--089e010d8a22e4b153053a01f23b
Content-Type: text/plain; charset=UTF-8

On Sat, Aug 13, 2016 at 11:42 PM, 'Walt Karas' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Saturday, August 13, 2016 at 9:38:23 PM UTC-4, Tony V E wrote:
>>
>> On Sat, Aug 13, 2016 at 7:55 PM, 'Walt Karas' via ISO C++ Standard -
>> Future Proposals <std-pr...@isocpp.org> wrote:
>>
>>> For the code:
>>>
>>> atomic<int> i;
>>> int sum = i.load(memory_order_relaxed);
>>> sum += i.load(memory_order_relaxed);
>>>
>>> both clang and gcc will load i from memory twice.  Was this the intent
>>> of the Standard?
>>>
>>> If an atomic instance is only ever written in a single thread, then
>>> loads in that thread can correctly be optimized out I think.  Do we need
>>> another memory order (memory_order_none perhaps) to indicate loads of the
>>> instance from memory are not necessary if the value of it is still in
>>> register(s) (due to a preceding load or store)?
>>>
>>> --
>>> 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-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit https://groups.google.com/a/is
>>> ocpp.org/d/msgid/std-proposals/51b50bc6-941e-4c52-b124-
>>> 6a0e98838a45%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/51b50bc6-941e-4c52-b124-6a0e98838a45%40isocpp.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
>> "No Sane Compiler Would Optimize Atomics"
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4455.html
>>
>>
>> Abstract: False.
>>
>>
>> This looks like something a compiler could (soon?) optimize.
>>
>
> I'm wondering if, given that this is not currently optimized, I should do
> something like:
>
> alignas(atomic<int>) int i;
> static_assert((ATOMIC_INT_LOCK_FREE == 2) and (sizeof(atomic<int>) ==
> sizeof(int)), "int not naturally atomic");
>
> and use calls to atomic_thread_fence() for memory access ordering
> requirements.
>


Only if you measure a performance difference.

--
Be seeing you,
Tony

--
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/CAOHCbis46FW%3DnGKiD1_sX7Wr_P_iKub%2BCjZ7nL-93T3SnYZw7A%40mail.gmail.com.

--089e010d8a22e4b153053a01f23b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, Aug 13, 2016 at 11:42 PM, &#39;Walt Karas&#39; via ISO C++ Stan=
dard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposa=
ls@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Saturday, August=
 13, 2016 at 9:38:23 PM UTC-4, Tony V E wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><span class=3D"=
">On Sat, Aug 13, 2016 at 7:55 PM, &#39;Walt Karas&#39; via ISO C++ Standar=
d - Future Proposals <span dir=3D"ltr">&lt;<a rel=3D"nofollow">std-pr...@is=
ocpp.org</a>&gt;</span> wrote:<br></span><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><span class=3D""><div dir=3D"ltr">For the code:<div><br></d=
iv><div>atomic&lt;int&gt; i;</div><div>int sum =3D i.load(memory_order_rela=
xed);</div><div>sum +=3D i.load(memory_order_relaxed);</div><div><br></div>=
<div>both clang and gcc will load i from memory twice.=C2=A0 Was this the i=
ntent of the Standard?</div><div><br></div><div>If an atomic instance is on=
ly ever written in a single thread, then loads in that thread can correctly=
 be optimized out I think.=C2=A0 Do we need another memory order (memory_or=
der_none perhaps) to indicate loads of the instance from memory are not nec=
essary if the value of it is still in register(s) (due to a preceding load =
or store)?</div></div></span><span><font color=3D"#888888"><span class=3D""=
>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span class=3D""><br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/51b50bc6-941e-4c52-b124-6a0e98838a45%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-pr=
oposals<wbr>/51b50bc6-941e-4c52-b124-<wbr>6a0e98838a45%40isocpp.org</a>.<br=
>
</span></font></span></blockquote></div><span class=3D""><br><br clear=3D"a=
ll"><div><div>&quot;No Sane Compiler Would Optimize Atomics&quot;<br><a hre=
f=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4455.html" re=
l=3D"nofollow" target=3D"_blank">http://www.open-std.org/jtc1/s<wbr>c22/wg2=
1/docs/papers/2015/n445<wbr>5.html</a><br></div><br><br>Abstract: False.<br=
><br><br></div>This looks like something a compiler could (soon?) optimize.=
</span></div></div></blockquote><div><br></div><div>I&#39;m wondering if, g=
iven that this is not currently optimized, I should do something like:</div=
><div><br></div><div>alignas(atomic&lt;int&gt;) int i;</div><div>static_ass=
ert((ATOMIC_INT_<wbr>LOCK_FREE =3D=3D 2) and (sizeof(atomic&lt;int&gt;) =3D=
=3D sizeof(int)), &quot;int not naturally atomic&quot;);<br></div><div><br>=
</div><div>and use calls to atomic_thread_fence() for memory access orderin=
g requirements.</div></div></blockquote><div><br><br></div><div>Only if you=
 measure a performance difference.<br></div><div>=C2=A0</div></div>-- <br><=
div class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=
=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></div>
</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/CAOHCbis46FW%3DnGKiD1_sX7Wr_P_iKub%2B=
CjZ7nL-93T3SnYZw7A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbis46FW%=
3DnGKiD1_sX7Wr_P_iKub%2BCjZ7nL-93T3SnYZw7A%40mail.gmail.com</a>.<br />

--089e010d8a22e4b153053a01f23b--

.


Author: "'Walt Karas' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Mon, 15 Aug 2016 09:29:23 -0700 (PDT)
Raw View
------=_Part_208_1888488373.1471278563422
Content-Type: multipart/alternative;
 boundary="----=_Part_209_827046577.1471278563422"

------=_Part_209_827046577.1471278563422
Content-Type: text/plain; charset=UTF-8

On Saturday, August 13, 2016 at 11:42:18 PM UTC-4, Walt Karas wrote:
>
> On Saturday, August 13, 2016 at 9:38:23 PM UTC-4, Tony V E wrote:
>>
>> On Sat, Aug 13, 2016 at 7:55 PM, 'Walt Karas' via ISO C++ Standard -
>> Future Proposals <std-pr...@isocpp.org> wrote:
>>
>>> For the code:
>>>
>>> atomic<int> i;
>>> int sum = i.load(memory_order_relaxed);
>>> sum += i.load(memory_order_relaxed);
>>>
>>> both clang and gcc will load i from memory twice.  Was this the intent
>>> of the Standard?
>>>
>>> If an atomic instance is only ever written in a single thread, then
>>> loads in that thread can correctly be optimized out I think.  Do we need
>>> another memory order (memory_order_none perhaps) to indicate loads of the
>>> instance from memory are not necessary if the value of it is still in
>>> register(s) (due to a preceding load or store)?
>>>
>>> --
>>> 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-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/51b50bc6-941e-4c52-b124-6a0e98838a45%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/51b50bc6-941e-4c52-b124-6a0e98838a45%40isocpp.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
>> "No Sane Compiler Would Optimize Atomics"
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4455.html
>>
>>
>> Abstract: False.
>>
>>
>> This looks like something a compiler could (soon?) optimize.
>>
>
> I'm wondering if, given that this is not currently optimized, I should do
> something like:
>
> alignas(atomic<int>) int i;
> static_assert((ATOMIC_INT_LOCK_FREE == 2) and (sizeof(atomic<int>) ==
> sizeof(int)), "int not naturally atomic");
>
> and use calls to atomic_thread_fence() for memory access ordering
> requirements.
>

For my particular use case, I believe I can use this function as a
work-around:

// If v is only ever written in one thread, it can be safely loaded in
// that thread as a non-atomic.
//
template <typename T>
inline T load_non_atomic(const std::atomic<T> &v)
  {
    if (sizeof(std::atomic<T>) == sizeof(T))
      return(* reinterpret_cast<const T *>(&v));
    else
      return(v.load(std::memory_order_relaxed));
  }


--
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/4f5a696e-9346-43b3-9ffb-ac9e5cf46883%40isocpp.org.

------=_Part_209_827046577.1471278563422
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, August 13, 2016 at 11:42:18 PM UTC-4, Walt Ka=
ras 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">On =
Saturday, August 13, 2016 at 9:38:23 PM UTC-4, Tony V E wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"=
>On Sat, Aug 13, 2016 at 7:55 PM, &#39;Walt Karas&#39; via ISO C++ Standard=
 - Future Proposals <span dir=3D"ltr">&lt;<a rel=3D"nofollow">std-pr...@iso=
cpp.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"ltr">For the code:<div><br></div><div>atomic&lt;int&gt;=
 i;</div><div>int sum =3D i.load(memory_order_relaxed);</div><div>sum +=3D =
i.load(memory_order_relaxed);</div><div><br></div><div>both clang and gcc w=
ill load i from memory twice.=C2=A0 Was this the intent of the Standard?</d=
iv><div><br></div><div>If an atomic instance is only ever written in a sing=
le thread, then loads in that thread can correctly be optimized out I think=
..=C2=A0 Do we need another memory order (memory_order_none perhaps) to indi=
cate loads of the instance from memory are not necessary if the value of it=
 is still in register(s) (due to a preceding load or store)?</div></div><sp=
an><font color=3D"#888888">

<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 rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</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/51b50bc6-941e-4c52-b124-6a0e98838a45%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/51b50bc6-941e-4c52-b124-6a0e98838a45%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/51b50bc6-941e-4c52-b124-6a0e98838a45%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/51b50bc6-941e-4c52-<wbr>b124-=
6a0e98838a45%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><div>&quot;No S=
ane Compiler Would Optimize Atomics&quot;<br><a href=3D"http://www.open-std=
..org/jtc1/sc22/wg21/docs/papers/2015/n4455.html" rel=3D"nofollow" target=3D=
"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhtt=
p%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fn4=
455.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHOMlCoFSJrf58FEzmesPY1HOBq=
rQ&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url=
?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F=
2015%2Fn4455.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHOMlCoFSJrf58FEzm=
esPY1HOBqrQ&#39;;return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/=
docs/papers/2015/<wbr>n4455.html</a><br></div><br><br>Abstract: False.<br><=
br><br></div>This looks like something a compiler could (soon?) optimize.</=
div></div></blockquote><div><br></div><div>I&#39;m wondering if, given that=
 this is not currently optimized, I should do something like:</div><div><br=
></div><div>alignas(atomic&lt;int&gt;) int i;</div><div>static_assert((ATOM=
IC_INT_<wbr>LOCK_FREE =3D=3D 2) and (sizeof(atomic&lt;int&gt;) =3D=3D sizeo=
f(int)), &quot;int not naturally atomic&quot;);<br></div><div><br></div><di=
v>and use calls to atomic_thread_fence() for memory access ordering require=
ments.</div></div></blockquote><div><br></div><div>For my particular use ca=
se, I believe I can use this function as a work-around:</div><div><br></div=
><div>// If v is only ever written in one thread, it can be safely loaded i=
n</div><div>// that thread as a non-atomic.</div><div>//</div><div>template=
 &lt;typename T&gt;</div><div>inline T load_non_atomic(const std::atomic&lt=
;T&gt; &amp;v)</div><div>=C2=A0 {</div><div>=C2=A0 =C2=A0 if (sizeof(std::a=
tomic&lt;T&gt;) =3D=3D sizeof(T))</div><div>=C2=A0 =C2=A0 =C2=A0 return(* r=
einterpret_cast&lt;const T *&gt;(&amp;v));</div><div>=C2=A0 =C2=A0 else</di=
v><div>=C2=A0 =C2=A0 =C2=A0 return(v.load(std::memory_order_relaxed));</div=
><div>=C2=A0 }</div><div>=C2=A0</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/4f5a696e-9346-43b3-9ffb-ac9e5cf46883%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4f5a696e-9346-43b3-9ffb-ac9e5cf46883=
%40isocpp.org</a>.<br />

------=_Part_209_827046577.1471278563422--

------=_Part_208_1888488373.1471278563422--

.