Topic: Proposal: add std::int_atomic8_t and std::uint_atomic8_t
Author: "'Walt Karas' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 28 Sep 2016 10:29:16 -0700 (PDT)
Raw View
------=_Part_582_1833652188.1475083756666
Content-Type: multipart/alternative;
boundary="----=_Part_583_479846690.1475083756666"
------=_Part_583_479846690.1475083756666
Content-Type: text/plain; charset=UTF-8
These would be synonyms for specializations of std::atomic for a signed,
unsigned integral type (respectively). They would be guaranteed to be
lock-free, and to have at least 8 bits of precision. Because sometimes
atomic_flag's one bit of precision doesn't cut it.
I think the requirement for atomic_flag already assumes that atomic<T> is
lock free for some integral type T. I think it's safe to assume that T has
at least 8 bits of precision. If 8 is too large as a lower bound on the
precision of T, another value, greater than 1, would still be an
improvement.
--
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/5715146b-d864-4ee7-b2f6-44c2834785a9%40isocpp.org.
------=_Part_583_479846690.1475083756666
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">These would be synonyms for specializations of std::atomic=
for a signed, unsigned integral type (respectively). =C2=A0They would be g=
uaranteed to be lock-free, and to have at least 8 bits of precision. =C2=A0=
Because sometimes atomic_flag's one bit of precision doesn't cut it=
..<div><br></div><div>I think the requirement for atomic_flag already assume=
s that atomic<T> is lock free for some integral type T. =C2=A0I think=
it's safe to assume that T has at least 8 bits of precision. =C2=A0If =
8 is too large as a lower bound on the precision of T, another value, great=
er than 1, would still be an improvement.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/5715146b-d864-4ee7-b2f6-44c2834785a9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5715146b-d864-4ee7-b2f6-44c2834785a9=
%40isocpp.org</a>.<br />
------=_Part_583_479846690.1475083756666--
------=_Part_582_1833652188.1475083756666--
.
Author: Anthony Williams <anthony.ajw@gmail.com>
Date: Wed, 28 Sep 2016 18:38:30 +0100
Raw View
On 28/09/16 18:29, 'Walt Karas' via ISO C++ Standard - Future Proposals
wrote:
> These would be synonyms for specializations of std::atomic for a signed,
> unsigned integral type (respectively). They would be guaranteed to be
> lock-free, and to have at least 8 bits of precision. Because sometimes
> atomic_flag's one bit of precision doesn't cut it.
>
> I think the requirement for atomic_flag already assumes that atomic<T>
> is lock free for some integral type T. I think it's safe to assume that
> T has at least 8 bits of precision. If 8 is too large as a lower bound
> on the precision of T, another value, greater than 1, would still be an
> improvement.
atomic_flag has a restricted interface (clear() and test_and_set() ONLY)
because there are some platforms where it is possible to make
atomic_flag lock-free, but it is not possible to make any other type
lock-free (even of the same size and alignment as atomic_flag) because
the required instructions don't exist.
Once you have a lock-free atomic_flag you can build a spinlock to make
atomic<T> "work", but atomic<T> cannot be lock-free without special
instructions.
You can use atomic<int8_t>, and on popular platforms this will be
lock-free, but it is not possible to guarantee a full-featured lock-free
atomic variable on all platforms supported by C++.
Anthony
--
Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/
just::thread C++11 thread library http://www.stdthread.co.uk
Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
--
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/a892b000-791b-089f-5ea7-af44a444edda%40gmail.com.
.
Author: "'Walt Karas' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 28 Sep 2016 10:45:55 -0700 (PDT)
Raw View
------=_Part_7213_641668993.1475084755473
Content-Type: multipart/alternative;
boundary="----=_Part_7214_1362026906.1475084755473"
------=_Part_7214_1362026906.1475084755473
Content-Type: text/plain; charset=UTF-8
On Wednesday, September 28, 2016 at 1:38:35 PM UTC-4, Anthony Williams
wrote:
>
> On 28/09/16 18:29, 'Walt Karas' via ISO C++ Standard - Future Proposals
> wrote:
> > These would be synonyms for specializations of std::atomic for a signed,
> > unsigned integral type (respectively). They would be guaranteed to be
> > lock-free, and to have at least 8 bits of precision. Because sometimes
> > atomic_flag's one bit of precision doesn't cut it.
> >
> > I think the requirement for atomic_flag already assumes that atomic<T>
> > is lock free for some integral type T. I think it's safe to assume that
> > T has at least 8 bits of precision. If 8 is too large as a lower bound
> > on the precision of T, another value, greater than 1, would still be an
> > improvement.
>
> atomic_flag has a restricted interface (clear() and test_and_set() ONLY)
> because there are some platforms where it is possible to make
> atomic_flag lock-free, but it is not possible to make any other type
> lock-free (even of the same size and alignment as atomic_flag) because
> the required instructions don't exist.
>
> Once you have a lock-free atomic_flag you can build a spinlock to make
> atomic<T> "work", but atomic<T> cannot be lock-free without special
> instructions.
>
> You can use atomic<int8_t>, and on popular platforms this will be
> lock-free, but it is not possible to guarantee a full-featured lock-free
> atomic variable on all platforms supported by C++.
>
> Anthony
> --
> Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/
> just::thread C++11 thread library http://www.stdthread.co.uk
> Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
> 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
>
Can you give an example of an architecture where there is no integral type
T where atomic<T> is lock free with "default" alignment?
--
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/b2f24908-4d81-4aba-a0f2-0145d03323d8%40isocpp.org.
------=_Part_7214_1362026906.1475084755473
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, September 28, 2016 at 1:38:35 PM UTC-4, Anth=
ony Williams wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 28/09/16=
18:29, 'Walt Karas' via ISO C++ Standard - Future Proposals
<br>wrote:
<br>> These would be synonyms for specializations of std::atomic for a s=
igned,
<br>> unsigned integral type (respectively). =C2=A0They would be guarant=
eed to be
<br>> lock-free, and to have at least 8 bits of precision. =C2=A0Because=
sometimes
<br>> atomic_flag's one bit of precision doesn't cut it.
<br>>=20
<br>> I think the requirement for atomic_flag already assumes that atomi=
c<T>
<br>> is lock free for some integral type T. =C2=A0I think it's safe=
to assume that
<br>> T has at least 8 bits of precision. =C2=A0If 8 is too large as a l=
ower bound
<br>> on the precision of T, another value, greater than 1, would still =
be an
<br>> improvement.
<br>
<br>atomic_flag has a restricted interface (clear() and test_and_set() ONLY=
)
<br>because there are some platforms where it is possible to make
<br>atomic_flag lock-free, but it is not possible to make any other type
<br>lock-free (even of the same size and alignment as atomic_flag) because
<br>the required instructions don't exist.
<br>
<br>Once you have a lock-free atomic_flag you can build a spinlock to make
<br>atomic<T> "work", but atomic<T> cannot be lock-fr=
ee without special
<br>instructions.
<br>
<br>You can use atomic<int8_t>, and on popular platforms this will be
<br>lock-free, but it is not possible to guarantee a full-featured lock-fre=
e
<br>atomic variable on all platforms supported by C++.
<br>
<br>Anthony
<br>--=20
<br>Author of C++ Concurrency in Action =C2=A0 =C2=A0 <a href=3D"http://www=
..stdthread.co.uk/book/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.stdthread.c=
o.uk%2Fbook%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHkNFD_k6fdkcq3HV83Az=
g2W_8v8g';return true;" onclick=3D"this.href=3D'http://www.google.c=
om/url?q\x3dhttp%3A%2F%2Fwww.stdthread.co.uk%2Fbook%2F\x26sa\x3dD\x26sntz\x=
3d1\x26usg\x3dAFQjCNHkNFD_k6fdkcq3HV83Azg2W_8v8g';return true;">http://=
www.stdthread.co.uk/<wbr>book/</a>
<br>just::thread C++11 thread library =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 <a href=3D"http://www.stdthread.co.uk" target=3D"_blank" rel=3D"nofo=
llow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3=
A%2F%2Fwww.stdthread.co.uk\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFtNeB_7b=
fnp2zcEgnSynTWCNWYkg';return true;" onclick=3D"this.href=3D'http://=
www.google.com/url?q\x3dhttp%3A%2F%2Fwww.stdthread.co.uk\x26sa\x3dD\x26sntz=
\x3d1\x26usg\x3dAFQjCNFtNeB_7bfnp2zcEgnSynTWCNWYkg';return true;">http:=
//www.stdthread.co.uk</a>
<br>Just Software Solutions Ltd =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.=
justsoftwaresolutions.co.uk" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.justso=
ftwaresolutions.co.uk\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH6cIjR6NHNwSY=
6t2QE8Ji7arrTmA';return true;" onclick=3D"this.href=3D'http://www.g=
oogle.com/url?q\x3dhttp%3A%2F%2Fwww.justsoftwaresolutions.co.uk\x26sa\x3dD\=
x26sntz\x3d1\x26usg\x3dAFQjCNH6cIjR6NHNwSY6t2QE8Ji7arrTmA';return true;=
">http://www.<wbr>justsoftwaresolutions.co.uk</a>
<br>15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 547897=
6
<br></blockquote><div><br></div><div>Can you give an example of an architec=
ture where there is no integral type T where atomic<T> is lock free w=
ith "default" alignment?=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" 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/b2f24908-4d81-4aba-a0f2-0145d03323d8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b2f24908-4d81-4aba-a0f2-0145d03323d8=
%40isocpp.org</a>.<br />
------=_Part_7214_1362026906.1475084755473--
------=_Part_7213_641668993.1475084755473--
.
Author: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 28 Sep 2016 11:00:08 -0700
Raw View
--001a113eb96cf301fb053d952219
Content-Type: text/plain; charset=UTF-8
On Wed, Sep 28, 2016 at 10:45 AM, 'Walt Karas' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> On Wednesday, September 28, 2016 at 1:38:35 PM UTC-4, Anthony Williams
> wrote:
>>
>> On 28/09/16 18:29, 'Walt Karas' via ISO C++ Standard - Future Proposals
>> wrote:
>> > These would be synonyms for specializations of std::atomic for a
>> signed,
>> > unsigned integral type (respectively). They would be guaranteed to be
>> > lock-free, and to have at least 8 bits of precision. Because sometimes
>> > atomic_flag's one bit of precision doesn't cut it.
>> >
>> > I think the requirement for atomic_flag already assumes that atomic<T>
>> > is lock free for some integral type T. I think it's safe to assume
>> that
>> > T has at least 8 bits of precision. If 8 is too large as a lower bound
>> > on the precision of T, another value, greater than 1, would still be an
>> > improvement.
>>
>> atomic_flag has a restricted interface (clear() and test_and_set() ONLY)
>> because there are some platforms where it is possible to make
>> atomic_flag lock-free, but it is not possible to make any other type
>> lock-free (even of the same size and alignment as atomic_flag) because
>> the required instructions don't exist.
>>
>> Once you have a lock-free atomic_flag you can build a spinlock to make
>> atomic<T> "work", but atomic<T> cannot be lock-free without special
>> instructions.
>>
>> You can use atomic<int8_t>, and on popular platforms this will be
>> lock-free, but it is not possible to guarantee a full-featured lock-free
>> atomic variable on all platforms supported by C++.
>>
>>
>>
> Can you give an example of an architecture where there is no integral type
> T where atomic<T> is lock free with "default" alignment?
>
I think it's just PA-RISC. I don't know if there are any C++11 compilers
for PA-RISC; probably not.
Jeffrey
--
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/CANh-dXm8wrpLB-GbxBN_n7nhbpPitA-NB3rFhtr5EUhkBEAM3g%40mail.gmail.com.
--001a113eb96cf301fb053d952219
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 W=
ed, Sep 28, 2016 at 10:45 AM, 'Walt Karas' via ISO C++ Standard - F=
uture Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@isocp=
p.org" class=3D"m_71195172645013182gmail-cremed m_71195172645013182cremed c=
remed" target=3D"_blank">std-proposals@isocpp.org</a>></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"><div><di=
v class=3D"m_71195172645013182gmail-h5">On Wednesday, September 28, 2016 at=
1:38:35 PM UTC-4, Anthony Williams wrote:<blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">On 28/09/16 18:29, 'Walt Karas' via ISO C++ Standa=
rd - Future Proposals
<br>wrote:
<br>> These would be synonyms for specializations of std::atomic for a s=
igned,
<br>> unsigned integral type (respectively).=C2=A0 They would be guarant=
eed to be
<br>> lock-free, and to have at least 8 bits of precision.=C2=A0 Because=
sometimes
<br>> atomic_flag's one bit of precision doesn't cut it.
<br>>=20
<br>> I think the requirement for atomic_flag already assumes that atomi=
c<T>
<br>> is lock free for some integral type T.=C2=A0 I think it's safe=
to assume that
<br>> T has at least 8 bits of precision.=C2=A0 If 8 is too large as a l=
ower bound
<br>> on the precision of T, another value, greater than 1, would still =
be an
<br>> improvement.
<br>
<br>atomic_flag has a restricted interface (clear() and test_and_set() ONLY=
)
<br>because there are some platforms where it is possible to make
<br>atomic_flag lock-free, but it is not possible to make any other type
<br>lock-free (even of the same size and alignment as atomic_flag) because
<br>the required instructions don't exist.
<br>
<br>Once you have a lock-free atomic_flag you can build a spinlock to make
<br>atomic<T> "work", but atomic<T> cannot be lock-fr=
ee without special
<br>instructions.
<br>
<br>You can use atomic<int8_t>, and on popular platforms this will be
<br>lock-free, but it is not possible to guarantee a full-featured lock-fre=
e
<br>atomic variable on all platforms supported by C++.
<br>
<br><br></blockquote><div><br></div></div></div><div>Can you give an exampl=
e of an architecture where there is no integral type T where atomic<T>=
; is lock free with "default" alignment?=C2=A0</div></div></block=
quote><div><br></div>I think it's just PA-RISC. I don't know if the=
re are any C++11 compilers for PA-RISC; probably not.</div><div class=3D"gm=
ail_quote"><br></div><div class=3D"gmail_quote">Jeffrey</div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CANh-dXm8wrpLB-GbxBN_n7nhbpPitA-NB3rF=
htr5EUhkBEAM3g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXm8wrpLB-Gb=
xBN_n7nhbpPitA-NB3rFhtr5EUhkBEAM3g%40mail.gmail.com</a>.<br />
--001a113eb96cf301fb053d952219--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 28 Sep 2016 21:04:37 +0300
Raw View
On 28 September 2016 at 21:00, 'Jeffrey Yasskin' via ISO C++ Standard
- Future Proposals <std-proposals@isocpp.org> wrote:
>> Can you give an example of an architecture where there is no integral type
>> T where atomic<T> is lock free with "default" alignment?
>
>
> I think it's just PA-RISC. I don't know if there are any C++11 compilers for
> PA-RISC; probably not.
Does GCC count?
--
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/CAFk2RUY%2BeiQj8aJ2DA3ziHKNYzuNKFhMmcrNYLbEkaVgKwe4vA%40mail.gmail.com.
.
Author: "'Walt Karas' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 28 Sep 2016 11:18:21 -0700 (PDT)
Raw View
------=_Part_622_1894120597.1475086701501
Content-Type: multipart/alternative;
boundary="----=_Part_623_571202740.1475086701501"
------=_Part_623_571202740.1475086701501
Content-Type: text/plain; charset=UTF-8
On Wednesday, September 28, 2016 at 2:04:38 PM UTC-4, Ville Voutilainen
wrote:
>
> On 28 September 2016 at 21:00, 'Jeffrey Yasskin' via ISO C++ Standard
> - Future Proposals <std-pr...@isocpp.org <javascript:>> wrote:
> >> Can you give an example of an architecture where there is no integral
> type
> >> T where atomic<T> is lock free with "default" alignment?
> >
> >
> > I think it's just PA-RISC. I don't know if there are any C++11 compilers
> for
> > PA-RISC; probably not.
>
>
> Does GCC count?
>
My bad, let me clarify, I mean "lock free" in a restricted sense, where
simple loads and stores are lock-free. But operations (like fetch_add)
that involve and load and a store are not necessarily lock-free.
--
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/bdf9407e-503a-41b2-8cfa-ae5fa7b9603a%40isocpp.org.
------=_Part_623_571202740.1475086701501
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, September 28, 2016 at 2:04:38 PM UTC=
-4, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On=
28 September 2016 at 21:00, 'Jeffrey Yasskin' via ISO C++ Standard
<br>- Future Proposals <<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"dWjT4lZfBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascri=
pt:';return true;">std-pr...@isocpp.org</a>> wrote:
<br>>> Can you give an example of an architecture where there is no i=
ntegral type
<br>>> T where atomic<T> is lock free with "default" =
alignment?
<br>>
<br>>
<br>> I think it's just PA-RISC. I don't know if there are any C=
++11 compilers for
<br>> PA-RISC; probably not.
<br>
<br>
<br>Does GCC count?
<br></blockquote><div><br></div><div>My bad, let me clarify, I mean "l=
ock free" in a restricted sense, where simple loads and stores are loc=
k-free. =C2=A0But operations (like fetch_add) that involve and load and a s=
tore are not necessarily lock-free.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/bdf9407e-503a-41b2-8cfa-ae5fa7b9603a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bdf9407e-503a-41b2-8cfa-ae5fa7b9603a=
%40isocpp.org</a>.<br />
------=_Part_623_571202740.1475086701501--
------=_Part_622_1894120597.1475086701501--
.
Author: Bo Persson <bop@gmb.dk>
Date: Wed, 28 Sep 2016 21:07:49 +0200
Raw View
On 2016-09-28 19:29, 'Walt Karas' via ISO C++ Standard - Future
Proposals wrote:
> These would be synonyms for specializations of std::atomic for a signed,
> unsigned integral type (respectively). They would be guaranteed to be
> lock-free, and to have at least 8 bits of precision. Because sometimes
> atomic_flag's one bit of precision doesn't cut it.
>
> I think the requirement for atomic_flag already assumes that atomic<T>
> is lock free for some integral type T. I think it's safe to assume that
> T has at least 8 bits of precision. If 8 is too large as a lower bound
> on the precision of T, another value, greater than 1, would still be an
> improvement.
>
Having a std::int_atomic8_t in addition to the existing
std::atomic_int8_t would be extremely confusing.
Can you not just limit the portability of your code to systems where
std::atomic<x>::is_always_lock_free is true for your selected type x?
Bo Persson
--
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/nsh4e5%24nqc%241%40blaine.gmane.org.
.
Author: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 28 Sep 2016 12:10:50 -0700
Raw View
--001a113ecfdac39462053d961f4c
Content-Type: text/plain; charset=UTF-8
On Wed, Sep 28, 2016 at 11:04 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 28 September 2016 at 21:00, 'Jeffrey Yasskin' via ISO C++ Standard
> - Future Proposals <std-proposals@isocpp.org> wrote:
> >> Can you give an example of an architecture where there is no integral
> type
> >> T where atomic<T> is lock free with "default" alignment?
> >
> >
> > I think it's just PA-RISC. I don't know if there are any C++11 compilers
> for
> > PA-RISC; probably not.
>
>
> Does GCC count?
>
If it targets PA-RISC and the library passes its tests, sure!
--
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/CANh-dXnRSuJhL3JgScV-92Emt6v1iRtmrwZ_Es%3DJNRvzPM3h3Q%40mail.gmail.com.
--001a113ecfdac39462053d961f4c
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 W=
ed, Sep 28, 2016 at 11:04 AM, Ville Voutilainen <span dir=3D"ltr"><<a hr=
ef=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank" class=3D"cremed=
">ville.voutilainen@gmail.com</a>></span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">On 28 September 2016 at 21:00, 'Jeffrey Yasskin' via ISO=
C++ Standard<br>
<span class=3D"">- Future Proposals <<a href=3D"mailto:std-proposals@iso=
cpp.org" class=3D"cremed">std-proposals@isocpp.org</a>> wrote:<br>
</span><span class=3D"">>> Can you give an example of an architecture=
where there is no integral type<br>
>> T where atomic<T> is lock free with "default" alig=
nment?<br>
><br>
><br>
> I think it's just PA-RISC. I don't know if there are any C++11=
compilers for<br>
> PA-RISC; probably not.<br>
<br>
<br>
</span>Does GCC count?<br></blockquote><div></div></div><br></div><div clas=
s=3D"gmail_extra">If it targets PA-RISC and the library passes its tests, s=
ure!</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CANh-dXnRSuJhL3JgScV-92Emt6v1iRtmrwZ_=
Es%3DJNRvzPM3h3Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXnRSuJhL3=
JgScV-92Emt6v1iRtmrwZ_Es%3DJNRvzPM3h3Q%40mail.gmail.com</a>.<br />
--001a113ecfdac39462053d961f4c--
.
Author: "'Walt Karas' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 28 Sep 2016 14:42:04 -0700 (PDT)
Raw View
------=_Part_675_1477490863.1475098924494
Content-Type: multipart/alternative;
boundary="----=_Part_676_2038147226.1475098924495"
------=_Part_676_2038147226.1475098924495
Content-Type: text/plain; charset=UTF-8
On Wednesday, September 28, 2016 at 3:08:07 PM UTC-4, Bo Persson wrote:
>
> On 2016-09-28 19:29, 'Walt Karas' via ISO C++ Standard - Future
> Proposals wrote:
> > These would be synonyms for specializations of std::atomic for a signed,
> > unsigned integral type (respectively). They would be guaranteed to be
> > lock-free, and to have at least 8 bits of precision. Because sometimes
> > atomic_flag's one bit of precision doesn't cut it.
> >
> > I think the requirement for atomic_flag already assumes that atomic<T>
> > is lock free for some integral type T. I think it's safe to assume that
> > T has at least 8 bits of precision. If 8 is too large as a lower bound
> > on the precision of T, another value, greater than 1, would still be an
> > improvement.
> >
>
> Having a std::int_atomic8_t in addition to the existing
> std::atomic_int8_t would be extremely confusing.
>
> Can you not just limit the portability of your code to systems where
> std::atomic<x>::is_always_lock_free is true for your selected type x?
>
>
>
> Bo Persson
Sorry, I think I've jumped the gun making a proposal. I was looking at
trying to make this old code portable and optimal using <atomic> :
http://wkaras.webs.com/spinlock_h.txt
http://wkaras.webs.com/spinlock_c.txt
Optimal in the sense that loads/stores of has_lock and flag[i] would
compile to a single load/store instruction (followed by a memory fence
instruction if needed). The best Idea I can come up with is to use
atomic_uint_fast8_t as the type of has_lock and flag[] .
Since Lamport's multi-way spinlock algorithm doesn't require atomic loads
and stores, maybe my code should be seen as moot. But it is a bit smaller
and simpler.
I don't think the PowerPC architecture has an instruction or other explicit
mechanism for doing an atomic test-and-set.
I wonder if there are implementations of test-and-set that use Lamport's
Bakery Algorithm to implement a spinlock. And then portable <atomic>-based
code for a spinlock uses the test-and-set, that is, it takes a spinlock to
make a spinlock.
--
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/43d1933a-7913-41a2-a679-ff41baaa2e0f%40isocpp.org.
------=_Part_676_2038147226.1475098924495
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, September 28, 2016 at 3:08:07 PM UTC=
-4, Bo Persson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-0=
9-28 19:29, 'Walt Karas' via ISO C++ Standard - Future=20
<br>Proposals wrote:
<br>> These would be synonyms for specializations of std::atomic for a s=
igned,
<br>> unsigned integral type (respectively). =C2=A0They would be guarant=
eed to be
<br>> lock-free, and to have at least 8 bits of precision. =C2=A0Because=
sometimes
<br>> atomic_flag's one bit of precision doesn't cut it.
<br>>
<br>> I think the requirement for atomic_flag already assumes that atomi=
c<T>
<br>> is lock free for some integral type T. =C2=A0I think it's safe=
to assume that
<br>> T has at least 8 bits of precision. =C2=A0If 8 is too large as a l=
ower bound
<br>> on the precision of T, another value, greater than 1, would still =
be an
<br>> improvement.
<br>>
<br>
<br>Having a std::int_atomic8_t in addition to the existing=20
<br>std::atomic_int8_t would be extremely confusing.
<br>
<br>Can you not just limit the portability of your code to systems where=20
<br>std::atomic<x>::is_always_<wbr>lock_free is true for your selecte=
d type x?
<br>
<br>
<br>
<br>=C2=A0 =C2=A0 =C2=A0Bo Persson=C2=A0</blockquote><div><br></div><div>So=
rry, I think I've jumped the gun making a proposal. =C2=A0I was looking=
at trying to make this old code portable and optimal using <atomic> =
:</div><div><br></div><div>http://wkaras.webs.com/spinlock_h.txt<br></div><=
div>http://wkaras.webs.com/spinlock_c.txt<br></div><div><br></div><div>Opti=
mal in the sense that loads/stores of has_lock and flag[i] would compile to=
a single load/store instruction (followed by a memory fence instruction if=
needed). =C2=A0The best Idea I can come up with is to use atomic_uint_fast=
8_t as the type of has_lock and flag[] .</div><div><br></div><div>Since Lam=
port's multi-way spinlock algorithm doesn't require atomic loads an=
d stores, maybe my code should be seen as moot. =C2=A0But it is a bit small=
er and simpler.</div><div><br></div><div>I don't think the PowerPC arch=
itecture has an instruction or other explicit mechanism for doing an atomic=
test-and-set.</div><div><br></div><div>I wonder if there are implementatio=
ns of test-and-set that use Lamport's Bakery Algorithm to implement a s=
pinlock. =C2=A0And then portable <atomic>-based code for a spinlock u=
ses the test-and-set, that is, it takes a spinlock to make a spinlock.</div=
></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/43d1933a-7913-41a2-a679-ff41baaa2e0f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/43d1933a-7913-41a2-a679-ff41baaa2e0f=
%40isocpp.org</a>.<br />
------=_Part_676_2038147226.1475098924495--
------=_Part_675_1477490863.1475098924494--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 28 Sep 2016 19:35:23 -0700
Raw View
On quarta-feira, 28 de setembro de 2016 14:42:04 PDT 'Walt Karas' via ISO C++
Standard - Future Proposals wrote:
> I don't think the PowerPC architecture has an instruction or other explicit
> mechanism for doing an atomic test-and-set.
It doesn't have an instruction for it, but it has a mechanism. Like most RISC
architectures, it uses Load Linked / Store Conditional. It also has the
funniest instruction name for a full barrier: eieio (GCC doesn't use it).
bool f(std::atomic<int> &i)
{ int e = 0; return i.compare_exchange_weak(e, 1); }
Produces with GCC 5.3.0 at -O2 -mregnames (comments mine):
_Z1fRSt6atomicIiE:
stwu %r1,-32(%r1)
li %r9,0
stw %r9,8(%r1)
sync ; acquire barrier
lwarx %r9,0,%r3 ; load linked
cmpwi %cr0,%r9,0 ; compare to 0
bne- %cr0,.L2
li %r9,1
stwcx. %r9,0,%r3 ; store conditional
..L2:
isync ; release barrier
mfcr %r3
rlwinm %r3,%r3,3,1
addi %r1,%r1,32
blr
You can try the same with Clang, but you'll notice it doesn't implement the
weak compare-and-swap, so it always loops. It also has no -mregnames, so you
have to decipher which parameters are registers and which ones are immediates.
It also uses yet another barrier instruction, which is not eieio.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/8164494.m5h71cUQmI%40tjmaciei-mobl1.
.