Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #69716 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2019-11-12 10:54 +0100 |
| Last post | 2019-11-14 11:45 +0100 |
| Articles | 20 on this page of 91 — 9 participants |
Back to article view | Back to comp.lang.c++
std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 10:54 +0100
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 11:24 +0100
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 14:11 +0100
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 14:39 +0100
Re: std::atomic<T>::is_lock_free() Bo Persson <bo@bo-persson.se> - 2019-11-12 16:46 +0100
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 17:40 +0100
Re: std::atomic<T>::is_lock_free() Bo Persson <bo@bo-persson.se> - 2019-11-12 20:23 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-12 15:21 -0800
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:09 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 06:34 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 22:00 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 07:26 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 22:33 -0800
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 22:33 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 07:51 +0100
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 07:50 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 23:14 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 10:43 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-12 15:14 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 13:11 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-14 07:53 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 16:57 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-14 08:16 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 17:26 +0100
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 17:28 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-14 08:30 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 17:33 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:41 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-15 09:31 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-15 12:59 -0800
Re: std::atomic<T>::is_lock_free() scott@slp53.sl.home (Scott Lurndal) - 2019-11-15 21:47 +0000
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-15 13:56 -0800
Re: std::atomic<T>::is_lock_free() scott@slp53.sl.home (Scott Lurndal) - 2019-11-16 18:07 +0000
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-16 13:55 -0800
Re: std::atomic<T>::is_lock_free() scott@slp53.sl.home (Scott Lurndal) - 2019-11-16 22:13 +0000
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-16 18:40 -0800
Re: std::atomic<T>::is_lock_free() James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-17 18:39 -0500
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-17 20:59 -0800
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-17 21:00 -0800
Re: std::atomic<T>::is_lock_free() James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-18 08:25 -0500
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-18 18:24 -0800
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-15 13:59 -0800
Re: std::atomic<T>::is_lock_free() Ian Collins <ian-news@hotmail.com> - 2019-11-16 11:08 +1300
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-15 15:39 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-16 07:22 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-16 08:06 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-16 17:13 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-16 08:26 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-16 19:27 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-16 10:37 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-16 19:47 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-16 11:34 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-17 09:17 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-17 01:52 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-17 11:23 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-17 03:22 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-17 14:20 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-17 06:39 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-17 15:49 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-17 22:54 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-18 08:03 +0100
Re: std::atomic<T>::is_lock_free() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 15:39 -0800
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-28 16:33 -0800
Re: std::atomic<T>::is_lock_free() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 22:48 -0800
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2020-01-11 00:24 -0800
Re: std::atomic<T>::is_lock_free() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-14 07:16 -0800
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2020-01-14 08:55 -0800
Re: std::atomic<T>::is_lock_free() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 02:01 -0800
Re: std::atomic<T>::is_lock_free() James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-21 06:00 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-17 15:58 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-17 21:01 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-18 07:00 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-17 22:45 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-18 07:52 +0100
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-18 08:10 +0100
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-17 23:23 -0800
Re: std::atomic<T>::is_lock_free() Ian Collins <ian-news@hotmail.com> - 2019-11-18 20:26 +1300
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-17 23:05 -0800
Re: std::atomic<T>::is_lock_free() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 15:44 -0800
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-28 16:43 -0800
Re: std::atomic<T>::is_lock_free() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-11 06:41 -0800
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:33 -0800
Re: std::atomic<T>::is_lock_free() Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-14 19:08 +0000
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 20:12 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:35 -0800
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:32 -0800
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:37 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-15 09:32 +0100
Re: std::atomic<T>::is_lock_free() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-15 13:06 -0800
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-14 02:29 -0800
Re: std::atomic<T>::is_lock_free() Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 11:45 +0100
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-11-14 07:53 -0800 |
| Message-ID | <469d274b-00e7-4126-afde-80bf7290bf54@googlegroups.com> |
| In reply to | #69716 |
On Thursday, 14 November 2019 12:45:48 UTC+2, Bonita Montero wrote: > > There may be difference between what same operating system > > provides (in its dynamic runtime library versions). These differences > > can be side by side available to same executable on same machine > > ... read up on "dll hell". Further there may be difference what these > > runtime libraries provide to variables of same type. For example it > > may depend on how variable of a type is (unavoidably) aligned in > > memory if it can be accessed without locks atomically. > > Lock-free Atomic operations don't depend on the operating-system, > the dll-hell (weird idea) or the runtime-libraries. And you can be > be sure that the specialized atomics that are lock-free are declared > to be properly aligned at the class-definition. > Do you want to compete with Melzzzz in expertise-unawareness? These were the points raised when C++11 atomics were coined: <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html#DiscussLockFree> Why don't you go and participate in standardization if you are better expert than those dimwits in working group 21.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-14 16:57 +0100 |
| Message-ID | <qqjthb$rhq$1@news.albasani.net> |
| In reply to | #69729 |
>>> There may be difference between what same operating system >>> provides (in its dynamic runtime library versions). These differences >>> can be side by side available to same executable on same machine >>> ... read up on "dll hell". Further there may be difference what these >>> runtime libraries provide to variables of same type. For example it >>> may depend on how variable of a type is (unavoidably) aligned in >>> memory if it can be accessed without locks atomically. >> Lock-free Atomic operations don't depend on the operating-system, >> the dll-hell (weird idea) or the runtime-libraries. And you can be >> be sure that the specialized atomics that are lock-free are declared >> to be properly aligned at the class-definition. >> Do you want to compete with Melzzzz in expertise-unawareness? > These were the points raised when C++11 atomics were coined: > <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html#DiscussLockFree> > Why don't you go and participate in standardization if you are better > expert than those dimwits in working group 21. This paper doesn't say why is_lock_free can be evaluated at runtime.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-11-14 08:16 -0800 |
| Message-ID | <3b58b4dd-b63a-46c6-8e4f-9ccfe0328d15@googlegroups.com> |
| In reply to | #69730 |
On Thursday, 14 November 2019 17:57:44 UTC+2, Bonita Montero wrote: > >>> There may be difference between what same operating system > >>> provides (in its dynamic runtime library versions). These differences > >>> can be side by side available to same executable on same machine > >>> ... read up on "dll hell". Further there may be difference what these > >>> runtime libraries provide to variables of same type. For example it > >>> may depend on how variable of a type is (unavoidably) aligned in > >>> memory if it can be accessed without locks atomically. > > >> Lock-free Atomic operations don't depend on the operating-system, > >> the dll-hell (weird idea) or the runtime-libraries. And you can be > >> be sure that the specialized atomics that are lock-free are declared > >> to be properly aligned at the class-definition. > >> Do you want to compete with Melzzzz in expertise-unawareness? > > > These were the points raised when C++11 atomics were coined: > > <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html#DiscussLockFree> > > Why don't you go and participate in standardization if you are better > > expert than those dimwits in working group 21. > > This paper doesn't say why is_lock_free can be evaluated at runtime. Note that universe can not be modified just by typing untruths. :D That is official paper and it continues to say why lock free query function was proposed to be dynamic per object for how long it is archived.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-14 17:26 +0100 |
| Message-ID | <qqjv8e$n35$2@news.albasani.net> |
| In reply to | #69732 |
>>>>> There may be difference between what same operating system >>>>> provides (in its dynamic runtime library versions). These differences >>>>> can be side by side available to same executable on same machine >>>>> ... read up on "dll hell". Further there may be difference what these >>>>> runtime libraries provide to variables of same type. For example it >>>>> may depend on how variable of a type is (unavoidably) aligned in >>>>> memory if it can be accessed without locks atomically. >>>> Lock-free Atomic operations don't depend on the operating-system, >>>> the dll-hell (weird idea) or the runtime-libraries. And you can be >>>> be sure that the specialized atomics that are lock-free are declared >>>> to be properly aligned at the class-definition. >>>> Do you want to compete with Melzzzz in expertise-unawareness? >>> These were the points raised when C++11 atomics were coined: >>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html#DiscussLockFree> >>> Why don't you go and participate in standardization if you are better >>> expert than those dimwits in working group 21. >> This paper doesn't say why is_lock_free can be evaluated at runtime. > Note that universe can not be modified just by typing untruths. :D > That is official paper and it continues to say why lock free query > function was proposed to be dynamic per object for how long it > is archived. Quote that statement of the paper.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-14 17:28 +0100 |
| Message-ID | <qqjvca$n35$3@news.albasani.net> |
| In reply to | #69734 |
> Quote that statement of the paper. Ok, you're right: "The proposal provides run-time lock-free query functions rather than compile-time constants because subsequent implementations of a platform may upgrade locking operations with lock-free operations, so it is common for systems to abstract such facilities behind dynamic libraries, and we wish to leave that possiblility open. Furthermore, we recommend that implementations without hardware atomic support use that technique." But that's rather an abstract and untechnical statement.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-11-14 08:30 -0800 |
| Message-ID | <beb9fe49-da6c-4488-a435-5aa71a070782@googlegroups.com> |
| In reply to | #69734 |
On Thursday, 14 November 2019 18:27:06 UTC+2, Bonita Montero wrote: > >>>>> There may be difference between what same operating system > >>>>> provides (in its dynamic runtime library versions). These differences > >>>>> can be side by side available to same executable on same machine > >>>>> ... read up on "dll hell". Further there may be difference what these > >>>>> runtime libraries provide to variables of same type. For example it > >>>>> may depend on how variable of a type is (unavoidably) aligned in > >>>>> memory if it can be accessed without locks atomically. > > >>>> Lock-free Atomic operations don't depend on the operating-system, > >>>> the dll-hell (weird idea) or the runtime-libraries. And you can be > >>>> be sure that the specialized atomics that are lock-free are declared > >>>> to be properly aligned at the class-definition. > >>>> Do you want to compete with Melzzzz in expertise-unawareness? > > >>> These were the points raised when C++11 atomics were coined: > >>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html#DiscussLockFree> > >>> Why don't you go and participate in standardization if you are better > >>> expert than those dimwits in working group 21. > > >> This paper doesn't say why is_lock_free can be evaluated at runtime. > > > Note that universe can not be modified just by typing untruths. :D > > That is official paper and it continues to say why lock free query > > function was proposed to be dynamic per object for how long it > > is archived. > > Quote that statement of the paper. The proposal provides lock-free query functions on individual objects rather than whole types to permit unavoidably misaligned atomic variables without penalizing the performance of aligned atomic variables.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-14 17:33 +0100 |
| Message-ID | <qqjvki$n35$4@news.albasani.net> |
| In reply to | #69736 |
> The proposal provides lock-free query functions on individual objects rather than whole types to permit unavoidably misaligned atomic variables without penalizing the performance of aligned atomic variables. That's rather stupid since the language says that access to unaligned data has an undefined behaviour. And there's not the least necessitiy in using unaligned atomics.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-14 13:41 -0800 |
| Message-ID | <qqkhm9$1e2a$1@gioia.aioe.org> |
| In reply to | #69737 |
On 11/14/2019 8:33 AM, Bonita Montero wrote: >> The proposal provides lock-free query functions on individual objects >> rather than whole types to permit unavoidably misaligned atomic >> variables without penalizing the performance of aligned atomic variables. > > That's rather stupid since the language says that access to unaligned > data has an undefined behaviour. And there's not the least necessitiy > in using unaligned atomics. You are JG, right?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-15 09:31 +0100 |
| Message-ID | <qqlnp9$3ed$1@news.albasani.net> |
| In reply to | #69747 |
>>> The proposal provides lock-free query functions on individual objects >>> rather than whole types to permit unavoidably misaligned atomic >>> variables without penalizing the performance of aligned atomic >>> variables. >> That's rather stupid since the language says that access to unaligned >> data has an undefined behaviour. And there's not the least necessitiy >> in using unaligned atomics. > You are JG, right? Tell me of the sense to use non-aligned atomics.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-15 12:59 -0800 |
| Message-ID | <qqn3ip$16u6$1@gioia.aioe.org> |
| In reply to | #69749 |
On 11/15/2019 12:31 AM, Bonita Montero wrote: >>>> The proposal provides lock-free query functions on individual >>>> objects rather than whole types to permit unavoidably misaligned >>>> atomic variables without penalizing the performance of aligned >>>> atomic variables. > >>> That's rather stupid since the language says that access to unaligned >>> data has an undefined behaviour. And there's not the least necessitiy >>> in using unaligned atomics. > >> You are JG, right? > > Tell me of the sense to use non-aligned atomics. Not sure what that even means. Are you talking about L2 cache alignment and proper padding? Its used to avoid false sharing.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-11-15 21:47 +0000 |
| Message-ID | <b2FzF.150668$oT5.19859@fx47.iad> |
| In reply to | #69769 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >On 11/15/2019 12:31 AM, Bonita Montero wrote: >>>>> The proposal provides lock-free query functions on individual >>>>> objects rather than whole types to permit unavoidably misaligned >>>>> atomic variables without penalizing the performance of aligned >>>>> atomic variables. >> >>>> That's rather stupid since the language says that access to unaligned >>>> data has an undefined behaviour. And there's not the least necessitiy >>>> in using unaligned atomics. >> >>> You are JG, right? >> >> Tell me of the sense to use non-aligned atomics. > >Not sure what that even means. Are you talking about L2 cache alignment >and proper padding? Its used to avoid false sharing. Why do you bother with BM? It deliberatly removes attributes so it's impossible to see who said what to whom. In any case, unaligned atomics are useless, and many architectures won't support them (particularly in uncachable memory regions like those mapped to PCI express bars (and PCI express endpoints -may- support atomic operations...)). I suspect that most architectures avoid supporting unaligned atomics because they might split cache lines which would make it impossible (or very time consuming) to support atomic semantics for the access.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-15 13:56 -0800 |
| Message-ID | <qqn6uj$1m73$1@gioia.aioe.org> |
| In reply to | #69773 |
On 11/15/2019 1:47 PM, Scott Lurndal wrote: > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >> On 11/15/2019 12:31 AM, Bonita Montero wrote: >>>>>> The proposal provides lock-free query functions on individual >>>>>> objects rather than whole types to permit unavoidably misaligned >>>>>> atomic variables without penalizing the performance of aligned >>>>>> atomic variables. >>> >>>>> That's rather stupid since the language says that access to unaligned >>>>> data has an undefined behaviour. And there's not the least necessitiy >>>>> in using unaligned atomics. >>> >>>> You are JG, right? >>> >>> Tell me of the sense to use non-aligned atomics. >> >> Not sure what that even means. Are you talking about L2 cache alignment >> and proper padding? Its used to avoid false sharing. > > Why do you bother with BM? It deliberatly removes attributes so > it's impossible to see who said what to whom. I think BM = JG. Its a sock puppet... > In any case, unaligned atomics are useless, and many architectures > won't support them (particularly in uncachable memory regions like > those mapped to PCI express bars (and PCI express endpoints -may- support atomic > operations...)). > > I suspect that most architectures avoid supporting unaligned atomics > because they might split cache lines which would make it impossible > (or very time consuming) to support atomic semantics for the access. > Well, I remember abusing unaligned atomics such that a word straddles a L2 cache line! Well, on x86 this should trigger a system wide bus lock for legacy reasons. It did something quite interesting. It acted like a remote memory barrier that makes it possible to implement asymmetric sync algorithms. There is a mention of it, need to find it. They called it something like QPI? Humm... Let me do a little search... [searching] Found it! https://blogs.oracle.com/dave/qpi-quiescence This is very hackish, but does allow for RCU. Also, fwiw, Windows has an interesting instruction: https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers That can provide a similar behavior. Iirc, it sends IPIs to an affinity mask of processors. This can be done in the Kernel with Windows. It takes a device driver.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-11-16 18:07 +0000 |
| Message-ID | <1WWzF.121832$Ys1.31748@fx42.iad> |
| In reply to | #69774 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>On 11/15/2019 1:47 PM, Scott Lurndal wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> On 11/15/2019 12:31 AM, Bonita Montero wrote:
>>>>>>> The proposal provides lock-free query functions on individual
>>>>>>> objects rather than whole types to permit unavoidably misaligned
>>>>>>> atomic variables without penalizing the performance of aligned
>>>>>>> atomic variables.
>>>>
>>>>>> That's rather stupid since the language says that access to unaligned
>>>>>> data has an undefined behaviour. And there's not the least necessitiy
>>>>>> in using unaligned atomics.
>>>>
>>>>> You are JG, right?
>>>>
>>>> Tell me of the sense to use non-aligned atomics.
>>>
>>> Not sure what that even means. Are you talking about L2 cache alignment
>>> and proper padding? Its used to avoid false sharing.
>>
>> Why do you bother with BM? It deliberatly removes attributes so
>> it's impossible to see who said what to whom.
>
>I think BM = JG. Its a sock puppet...
>
>> In any case, unaligned atomics are useless, and many architectures
>> won't support them (particularly in uncachable memory regions like
>> those mapped to PCI express bars (and PCI express endpoints -may- support atomic
>> operations...)).
>>
>> I suspect that most architectures avoid supporting unaligned atomics
>> because they might split cache lines which would make it impossible
>> (or very time consuming) to support atomic semantics for the access.
>>
>
>Well, I remember abusing unaligned atomics such that a word straddles a
>L2 cache line! Well, on x86 this should trigger a system wide bus lock
>for legacy reasons.
Yes, that's the "very time consuming" part.
We (3Leaf Systems) designed a chip in the mid 2000s that connected
to the processor via Hypertransport (Opteron) or QPI (Intel) and
extended the processor coherency domain over Infiniband[*] to another
instance of our chip (allowing creation of large shared memory
systems consisting of commodity 1u or 2u rack mount SMP boxes).
One of the national labs was benchmarking the system by pounding on
a spinlock from all 128 cores (across 16 2-socket nodes).
A little known characteristic of AMD and Intel
processors is that if a processor isn't making progress on acquiring
a highly contended cache-line, it will at some point decide to obtain the
system bus lock.
Needless to say, performance was shit (although the test was designed
to show this behavior and was not representative of the labs normal
workloads on the system).
[*] The chip had 2MByte of DRAM caching remote lines, a miss cost about
800 ns round trip (using DDR IB) on the HT systems, and 500ns on QPI (using QDR IB).
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-16 13:55 -0800 |
| Message-ID | <qqpr94$1cem$1@gioia.aioe.org> |
| In reply to | #69811 |
On 11/16/2019 10:07 AM, Scott Lurndal wrote: > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >> On 11/15/2019 1:47 PM, Scott Lurndal wrote: >>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >>>> On 11/15/2019 12:31 AM, Bonita Montero wrote: >>>>>>>> The proposal provides lock-free query functions on individual >>>>>>>> objects rather than whole types to permit unavoidably misaligned >>>>>>>> atomic variables without penalizing the performance of aligned >>>>>>>> atomic variables. >>>>> >>>>>>> That's rather stupid since the language says that access to unaligned >>>>>>> data has an undefined behaviour. And there's not the least necessitiy >>>>>>> in using unaligned atomics. >>>>> >>>>>> You are JG, right? >>>>> >>>>> Tell me of the sense to use non-aligned atomics. >>>> >>>> Not sure what that even means. Are you talking about L2 cache alignment >>>> and proper padding? Its used to avoid false sharing. >>> >>> Why do you bother with BM? It deliberatly removes attributes so >>> it's impossible to see who said what to whom. >> >> I think BM = JG. Its a sock puppet... >> >>> In any case, unaligned atomics are useless, and many architectures >>> won't support them (particularly in uncachable memory regions like >>> those mapped to PCI express bars (and PCI express endpoints -may- support atomic >>> operations...)). >>> >>> I suspect that most architectures avoid supporting unaligned atomics >>> because they might split cache lines which would make it impossible >>> (or very time consuming) to support atomic semantics for the access. >>> >> >> Well, I remember abusing unaligned atomics such that a word straddles a >> L2 cache line! Well, on x86 this should trigger a system wide bus lock >> for legacy reasons. > > Yes, that's the "very time consuming" part. Indeed. A forced unaligned atomic access wrt hacking RCU was amortized and used on a fairly rare basis. Think along the lines of read-"mostly" usage patterns. Wrt RCU, we can collect garbage on a per-thread basis, and when a threads garbage gets over a "threshold", it can decide to execute a system wide membar, or something else. The asymmetric side of things is to have a fast side, and a slow side... The fast are the readers, the slow is the writers. Readers can run full steam ahead, and do not interfere with writers. > > We (3Leaf Systems) designed a chip in the mid 2000s that connected > to the processor via Hypertransport (Opteron) or QPI (Intel) and > extended the processor coherency domain over Infiniband[*] to another > instance of our chip (allowing creation of large shared memory > systems consisting of commodity 1u or 2u rack mount SMP boxes). > > One of the national labs was benchmarking the system by pounding on > a spinlock from all 128 cores (across 16 2-socket nodes). YIKES! Hammer time. ;^) > > A little known characteristic of AMD and Intel > processors is that if a processor isn't making progress on acquiring > a highly contended cache-line, it will at some point decide to obtain the > system bus lock. > > Needless to say, performance was shit (although the test was designed > to show this behavior and was not representative of the labs normal > workloads on the system). > > [*] The chip had 2MByte of DRAM caching remote lines, a miss cost about > 800 ns round trip (using DDR IB) on the HT systems, and 500ns on QPI (using QDR IB). > Did you try using hash tables just to experiment wrt taking pressure off of a single lock? Even that does not scale all that great. However, its better than a single funnel... ;^)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-11-16 22:13 +0000 |
| Message-ID | <dw_zF.18674$bC3.9879@fx08.iad> |
| In reply to | #69835 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >On 11/16/2019 10:07 AM, Scott Lurndal wrote: >> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >>> On 11/15/2019 1:47 PM, Scott Lurndal wrote: >>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >>>>> On 11/15/2019 12:31 AM, Bonita Montero wrote: >>>>>>>>> The proposal provides lock-free query functions on individual >>>>>>>>> objects rather than whole types to permit unavoidably misaligned >>>>>>>>> atomic variables without penalizing the performance of aligned >>>>>>>>> atomic variables. >>>>>> >>>>>>>> That's rather stupid since the language says that access to unaligned >>>>>>>> data has an undefined behaviour. And there's not the least necessitiy >>>>>>>> in using unaligned atomics. >>>>>> >>>>>>> You are JG, right? >>>>>> >>>>>> Tell me of the sense to use non-aligned atomics. >>>>> >>>>> Not sure what that even means. Are you talking about L2 cache alignment >>>>> and proper padding? Its used to avoid false sharing. >>>> >>>> Why do you bother with BM? It deliberatly removes attributes so >>>> it's impossible to see who said what to whom. >>> >>> I think BM = JG. Its a sock puppet... >>> >>>> In any case, unaligned atomics are useless, and many architectures >>>> won't support them (particularly in uncachable memory regions like >>>> those mapped to PCI express bars (and PCI express endpoints -may- support atomic >>>> operations...)). >>>> >>>> I suspect that most architectures avoid supporting unaligned atomics >>>> because they might split cache lines which would make it impossible >>>> (or very time consuming) to support atomic semantics for the access. >>>> >>> >>> Well, I remember abusing unaligned atomics such that a word straddles a >>> L2 cache line! Well, on x86 this should trigger a system wide bus lock >>> for legacy reasons. >> >> Yes, that's the "very time consuming" part. > >Indeed. A forced unaligned atomic access wrt hacking RCU was amortized >and used on a fairly rare basis. Think along the lines of read-"mostly" >usage patterns. Wrt RCU, we can collect garbage on a per-thread basis, >and when a threads garbage gets over a "threshold", it can decide to >execute a system wide membar, or something else. The asymmetric side of >things is to have a fast side, and a slow side... The fast are the >readers, the slow is the writers. Readers can run full steam ahead, and >do not interfere with writers. > >> >> We (3Leaf Systems) designed a chip in the mid 2000s that connected >> to the processor via Hypertransport (Opteron) or QPI (Intel) and >> extended the processor coherency domain over Infiniband[*] to another >> instance of our chip (allowing creation of large shared memory >> systems consisting of commodity 1u or 2u rack mount SMP boxes). >> >> One of the national labs was benchmarking the system by pounding on >> a spinlock from all 128 cores (across 16 2-socket nodes). > >YIKES! Hammer time. ;^) > >> >> A little known characteristic of AMD and Intel >> processors is that if a processor isn't making progress on acquiring >> a highly contended cache-line, it will at some point decide to obtain the >> system bus lock. >> >> Needless to say, performance was shit (although the test was designed >> to show this behavior and was not representative of the labs normal >> workloads on the system). >> >> [*] The chip had 2MByte of DRAM caching remote lines, a miss cost about >> 800 ns round trip (using DDR IB) on the HT systems, and 500ns on QPI (using QDR IB). >> > >Did you try using hash tables just to experiment wrt taking pressure off >of a single lock? Even that does not scale all that great. However, its >better than a single funnel... ;^) The purpose of the test was to see what happened when all cores contended for the same line (running slow is expected, crashing (which we didn't) isn't). Actual lab codes were much better structured from a parallelism standpoint.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-16 18:40 -0800 |
| Message-ID | <qqqbvj$1ki8$1@gioia.aioe.org> |
| In reply to | #69836 |
On 11/16/2019 2:13 PM, Scott Lurndal wrote: > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >> On 11/16/2019 10:07 AM, Scott Lurndal wrote: >>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >>>> On 11/15/2019 1:47 PM, Scott Lurndal wrote: >>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >>>>>> On 11/15/2019 12:31 AM, Bonita Montero wrote: >>>>>>>>>> The proposal provides lock-free query functions on individual >>>>>>>>>> objects rather than whole types to permit unavoidably misaligned >>>>>>>>>> atomic variables without penalizing the performance of aligned >>>>>>>>>> atomic variables. >>>>>>> >>>>>>>>> That's rather stupid since the language says that access to unaligned >>>>>>>>> data has an undefined behaviour. And there's not the least necessitiy >>>>>>>>> in using unaligned atomics. >>>>>>> >>>>>>>> You are JG, right? >>>>>>> >>>>>>> Tell me of the sense to use non-aligned atomics. >>>>>> >>>>>> Not sure what that even means. Are you talking about L2 cache alignment >>>>>> and proper padding? Its used to avoid false sharing. >>>>> >>>>> Why do you bother with BM? It deliberatly removes attributes so >>>>> it's impossible to see who said what to whom. >>>> >>>> I think BM = JG. Its a sock puppet... >>>> >>>>> In any case, unaligned atomics are useless, and many architectures >>>>> won't support them (particularly in uncachable memory regions like >>>>> those mapped to PCI express bars (and PCI express endpoints -may- support atomic >>>>> operations...)). >>>>> >>>>> I suspect that most architectures avoid supporting unaligned atomics >>>>> because they might split cache lines which would make it impossible >>>>> (or very time consuming) to support atomic semantics for the access. >>>>> >>>> >>>> Well, I remember abusing unaligned atomics such that a word straddles a >>>> L2 cache line! Well, on x86 this should trigger a system wide bus lock >>>> for legacy reasons. >>> >>> Yes, that's the "very time consuming" part. >> >> Indeed. A forced unaligned atomic access wrt hacking RCU was amortized >> and used on a fairly rare basis. Think along the lines of read-"mostly" >> usage patterns. Wrt RCU, we can collect garbage on a per-thread basis, >> and when a threads garbage gets over a "threshold", it can decide to >> execute a system wide membar, or something else. The asymmetric side of >> things is to have a fast side, and a slow side... The fast are the >> readers, the slow is the writers. Readers can run full steam ahead, and >> do not interfere with writers. >> >>> >>> We (3Leaf Systems) designed a chip in the mid 2000s that connected >>> to the processor via Hypertransport (Opteron) or QPI (Intel) and >>> extended the processor coherency domain over Infiniband[*] to another >>> instance of our chip (allowing creation of large shared memory >>> systems consisting of commodity 1u or 2u rack mount SMP boxes). >>> >>> One of the national labs was benchmarking the system by pounding on >>> a spinlock from all 128 cores (across 16 2-socket nodes). >> >> YIKES! Hammer time. ;^) >> >>> >>> A little known characteristic of AMD and Intel >>> processors is that if a processor isn't making progress on acquiring >>> a highly contended cache-line, it will at some point decide to obtain the >>> system bus lock. >>> >>> Needless to say, performance was shit (although the test was designed >>> to show this behavior and was not representative of the labs normal >>> workloads on the system). >>> >>> [*] The chip had 2MByte of DRAM caching remote lines, a miss cost about >>> 800 ns round trip (using DDR IB) on the HT systems, and 500ns on QPI (using QDR IB). >>> >> >> Did you try using hash tables just to experiment wrt taking pressure off >> of a single lock? Even that does not scale all that great. However, its >> better than a single funnel... ;^) > > The purpose of the test was to see what happened when all cores contended > for the same line (running slow is expected, crashing (which we didn't) isn't). > > Actual lab codes were much better structured from a parallelism standpoint. > It should not crash, slowing to a crawl is expected.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-11-17 18:39 -0500 |
| Message-ID | <qqslmv$mms$1@dont-email.me> |
| In reply to | #69850 |
On 11/16/19 9:40 PM, Chris M. Thomasson wrote: > On 11/16/2019 2:13 PM, Scott Lurndal wrote: ... >> ... running slow is expected, crashing ... isn't). ... > It should not crash, slowing to a crawl is expected. You just said the same thing, with slightly different wording. Your point?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-17 20:59 -0800 |
| Message-ID | <qqt8f6$a31$1@gioia.aioe.org> |
| In reply to | #69870 |
On 11/17/2019 3:39 PM, James Kuyper wrote: > On 11/16/19 9:40 PM, Chris M. Thomasson wrote: >> On 11/16/2019 2:13 PM, Scott Lurndal wrote: > ... >>> ... running slow is expected, crashing ... isn't). > ... >> It should not crash, slowing to a crawl is expected. > > You just said the same thing, with slightly different wording. Your point? > My point is that hammering a single mutex should not crash the system. It will most likely slow it to a crawl. Not start crashing processes left and right...
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-17 21:00 -0800 |
| Message-ID | <qqt8h8$a31$2@gioia.aioe.org> |
| In reply to | #69872 |
On 11/17/2019 8:59 PM, Chris M. Thomasson wrote: > On 11/17/2019 3:39 PM, James Kuyper wrote: >> On 11/16/19 9:40 PM, Chris M. Thomasson wrote: >>> On 11/16/2019 2:13 PM, Scott Lurndal wrote: >> ... >>>> ... running slow is expected, crashing ... isn't). >> ... >>> It should not crash, slowing to a crawl is expected. >> >> You just said the same thing, with slightly different wording. Your >> point? >> > > My point is that hammering a single mutex should not crash the system. > It will most likely slow it to a crawl. Not start crashing processes > left and right... > Well, the processes will be working, just going really, really slow. I hope its not like a slug hiking up a mountain of salt.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-11-18 08:25 -0500 |
| Message-ID | <qqu63o$i0g$1@dont-email.me> |
| In reply to | #69872 |
On 11/17/19 11:59 PM, Chris M. Thomasson wrote: > On 11/17/2019 3:39 PM, James Kuyper wrote: >> On 11/16/19 9:40 PM, Chris M. Thomasson wrote: >>> On 11/16/2019 2:13 PM, Scott Lurndal wrote: >> ... >>>> ... running slow is expected, crashing ... isn't). >> ... >>> It should not crash, slowing to a crawl is expected. >> >> You just said the same thing, with slightly different wording. Your point? >> > > My point is that hammering a single mutex should not crash the system. But, Scott already said that a crashing was not expected, so why the "me too" post?
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.c++
csiph-web