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 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-18 18:24 -0800 |
| Message-ID | <qqvjoq$15dd$1@gioia.aioe.org> |
| In reply to | #69886 |
On 11/18/2019 5:25 AM, James Kuyper wrote: > 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? > Habit? Sorry.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-15 13:59 -0800 |
| Message-ID | <qqn74e$1muh$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. [...] Actually, I have asked it to use proper quoting for some time now. Also, it acts like the following thing: https://zork.fandom.com/wiki/Cruel_Puppet Sometimes, it feels like I am casting my pearls before something... ;^o Might have to stop feeding it.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-11-16 11:08 +1300 |
| Message-ID | <h38lvmF4cl5U19@mid.individual.net> |
| In reply to | #69775 |
On 16/11/2019 10:59, Chris M. Thomasson wrote: > > Actually, I have asked it to use proper quoting for some time now. Also, > it acts like the following thing: > > https://zork.fandom.com/wiki/Cruel_Puppet > > Sometimes, it feels like I am casting my pearls before something... ;^o > > Might have to stop feeding it. Please do! -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-11-15 15:39 -0800 |
| Message-ID | <98e27cbe-79a4-4875-8aaa-a45c1eab293d@googlegroups.com> |
| In reply to | #69749 |
On Friday, 15 November 2019 10:31:47 UTC+2, 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. Huh? But it makes sense on hundreds of cases? You said that paper n2427 by Hans-J. Boehm and Dr. Lawrence Crowl is rather stupid. So now you tell what you think are most common (minimum 3 different) use cases for atomic access and similarly common use cases for __attribute__((packed)) and then tell why all (minimally 9) combined cases are "rather stupid" to expect to coincide to same object.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-16 07:22 +0100 |
| Message-ID | <qqo4i8$rl5$1@news.albasani.net> |
| In reply to | #69779 |
> You said that paper n2427 by Hans-J. Boehm and Dr. Lawrence Crowl > is rather stupid. So now you tell what you think are most common > (minimum 3 different) use cases for atomic access and similarly > common use cases for __attribute__((packed)) and then tell why > all (minimally 9) combined cases are "rather stupid" to expect > to coincide to same object. Why should I tell that? C++ has no support for unaligned accesses. And __attribute__((packed)) isn't C++.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-11-16 08:06 -0800 |
| Message-ID | <4a9ef580-84eb-4782-8d9a-440504086ca1@googlegroups.com> |
| In reply to | #69780 |
On Saturday, 16 November 2019 08:22:11 UTC+2, Bonita Montero wrote: > > You said that paper n2427 by Hans-J. Boehm and Dr. Lawrence Crowl > > is rather stupid. So now you tell what you think are most common > > (minimum 3 different) use cases for atomic access and similarly > > common use cases for __attribute__((packed)) and then tell why > > all (minimally 9) combined cases are "rather stupid" to expect > > to coincide to same object. > > Why should I tell that? C++ has no support for unaligned accesses. > And __attribute__((packed)) isn't C++. Because otherwise you look like piece of shit. Standard left alignment up to implementation to define. It even says that implementation may define it differently for whole objects and subjects. So ways to let programmer to alter what implementation defines are yes not part of standard but present in every implementation worth to mention.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-16 17:13 +0100 |
| Message-ID | <qqp76b$o3q$1@news.albasani.net> |
| In reply to | #69790 |
>> Why should I tell that? C++ has no support for unaligned accesses. >> And __attribute__((packed)) isn't C++. > Because otherwise you look like piece of shit. > Standard left alignment up to implementation to define. The standard doesn't support unaligned accesses and thereby indirectly defines that all data-types declared in the way the standard defines have a proper alignment. So also the atomics have a proper alignment. So there's no explicit need for the standard to support unaligned accesses.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-11-16 08:26 -0800 |
| Message-ID | <c000d68d-bc76-4ff9-bc54-d23d6067ebc8@googlegroups.com> |
| In reply to | #69792 |
On Saturday, 16 November 2019 18:13:10 UTC+2, Bonita Montero wrote: > >> Why should I tell that? C++ has no support for unaligned accesses. > >> And __attribute__((packed)) isn't C++. > > > Because otherwise you look like piece of shit. > > > Standard left alignment up to implementation to define. > > The standard doesn't support Not in this reality. Standard has fully left it up to implementation to decide if alignment of say int member in a particular struct is 1 or 2 or 4 or 8 and why. Seems that you don't know standard and also you don't know any use cases for packed structs and therefore wiggle pathetically.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-16 19:27 +0100 |
| Message-ID | <qqpf3c$ff3$1@news.albasani.net> |
| In reply to | #69795 |
>>>> Why should I tell that? C++ has no support for unaligned accesses. >>>> And __attribute__((packed)) isn't C++. >>> Because otherwise you look like piece of shit. >>> Standard left alignment up to implementation to define. >> The standard doesn't support > Not in this reality. Standard has fully left it up to implementation > to decide if alignment of say int member in a particular struct is 1 > or 2 or 4 or 8 and why. I didn't say any contrary. > Seems that you don't know standard and also you don't know any > use cases for packed structs and therefore wiggle pathetically. You can't even read what I said.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-11-16 10:37 -0800 |
| Message-ID | <633f2371-1a23-4ba5-a2ac-1de2b8109a9b@googlegroups.com> |
| In reply to | #69814 |
On Saturday, 16 November 2019 20:28:04 UTC+2, Bonita Montero wrote: > >>>> Why should I tell that? C++ has no support for unaligned accesses. > >>>> And __attribute__((packed)) isn't C++. > > >>> Because otherwise you look like piece of shit. > > >>> Standard left alignment up to implementation to define. > > >> The standard doesn't support > > > Not in this reality. Standard has fully left it up to implementation > > to decide if alignment of say int member in a particular struct is 1 > > or 2 or 4 or 8 and why. > > I didn't say any contrary. > > > Seems that you don't know standard and also you don't know any > > use cases for packed structs and therefore wiggle pathetically. > > You can't even read what I said. You just try to wiggle away from giving 3 examples when packed structs are most commonly used. Nonsense claims that standard does not allow implementations to have those packed structs do not hold. The packed structs (supported by all compilers) are not violating standard. Compilers do not need to give any diagnostics when packed structs are used. So pick some other direction to what to wiggle.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-16 19:47 +0100 |
| Message-ID | <qqpg75$d6m$1@news.albasani.net> |
| In reply to | #69816 |
>>> Seems that you don't know standard and also you don't know any >>> use cases for packed structs and therefore wiggle pathetically. >> You can't even read what I said. > You just try to wiggle away from giving 3 examples when packed > structs are most commonly used. They might be used, but packed structures with result in unaligned members have undefined behaviour. C an C++ knows a natural alignment for any complete datatype and every datatype must have this align- ment to be portable. So you can assume that a conformant implmentation of std:atomic has an appropriate alignment on std::atomic<T> for any T. So there is no inherent need to support is_lock_free for alignment-issues and there must be another good reason because for this is evaluated at runtime. > Nonsense claims that standard does not allow implementations > to have those packed structs do not hold. The discussion was about the need for is_lock_Free because of any alignment-issues. > The packed structs (supported by all compilers) are not violating > standard. Of course they do. Accessing a non-aligned variable is not portable.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-11-16 11:34 -0800 |
| Message-ID | <b294252d-efe1-4ec4-9314-614aed5c541b@googlegroups.com> |
| In reply to | #69818 |
On Saturday, 16 November 2019 20:47:13 UTC+2, Bonita Montero wrote: > >>> Seems that you don't know standard and also you don't know any > >>> use cases for packed structs and therefore wiggle pathetically. > > >> You can't even read what I said. > > > You just try to wiggle away from giving 3 examples when packed > > structs are most commonly used. > > They might be used, but packed structures with result in unaligned > members have undefined behaviour. C an C++ knows a natural alignment > for any complete datatype and every datatype must have this align- > ment to be portable. Nonsense. What is aligned or misaligned is up to compiler itself to decide. So if compiler itself put a member of struct into position misaligned for underlying processor then also compiler has to generate code that makes reads and writes of that member to behave well defined. > So you can assume that a conformant implmentation of std:atomic > has an appropriate alignment on std::atomic<T> for any T. So there > is no inherent need to support is_lock_free for alignment-issues > and there must be another good reason because for this is evaluated > at runtime. More nonsense. Nothing in standard says that all objects of type std::atomic<T> are aligned in a way that reads and writes to those objects can be made lock free. On the contrary. It may be different for different std::atomic<T> members of same object and different for same std::atomic<T> member of different objects. Therefore if you want to know that about concrete object you have to call is_lock_free() to it to find it out. > > > Nonsense claims that standard does not allow implementations > > to have those packed structs do not hold. > > The discussion was about the need for is_lock_Free because of any > alignment-issues. > > > The packed structs (supported by all compilers) are not violating > > standard. > > Of course they do. Accessing a non-aligned variable is not portable. You now try to break nonsense-meter of mine? :D That is impossible. Packed structs are quite often used to achieve processor-agnostic, language-agnostic and operating-system-agnostic bit-layouts of data. So those are one of tools for having portable data.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-17 09:17 +0100 |
| Message-ID | <qqqvm9$8lt$1@news.albasani.net> |
| In reply to | #69821 |
>> They might be used, but packed structures with result in unaligned
>> members have undefined behaviour. C an C++ knows a natural alignment
>> for any complete datatype and every datatype must have this align-
>> ment to be portable.
> Nonsense. What is aligned or misaligned is up to compiler
> itself to decide. ...
We're not talking about certain implementations but the language.
And unaligned accesses simply aren't portable.
>> So you can assume that a conformant implmentation of std:atomic
>> has an appropriate alignment on std::atomic<T> for any T. So there
>> is no inherent need to support is_lock_free for alignment-issues
>> and there must be another good reason because for this is evaluated
>> at runtime.
> More nonsense. Nothing in standard says that all objects of type
> std::atomic<T> are aligned in a way that reads and writes to those
> objects can be made lock free.
You can't read. I did say:
1. All complete types have a natural alignment.
2. std::atomic<T> thereby has also a natural alignment.
3. is_lock_free couldn't be dynamic because of runtime alignment
properties because C++ doesn't support unaligned acceses anyway.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-11-17 01:52 -0800 |
| Message-ID | <6296f03e-f997-4df4-a64a-205548147fb2@googlegroups.com> |
| In reply to | #69852 |
On Sunday, 17 November 2019 10:17:23 UTC+2, Bonita Montero wrote: > >> They might be used, but packed structures with result in unaligned > >> members have undefined behaviour. C an C++ knows a natural alignment > >> for any complete datatype and every datatype must have this align- > >> ment to be portable. > > > Nonsense. What is aligned or misaligned is up to compiler > > itself to decide. ... > > We're not talking about certain implementations but the language. > And unaligned accesses simply aren't portable. I wasn't tslking about concrete compiler. Standard is specification of C++ compilers and I was writing what standard allows and requires conforming compilers to do. The compilers that did not do what standard requires have gradually lost their market share. > >> So you can assume that a conformant implmentation of std:atomic > >> has an appropriate alignment on std::atomic<T> for any T. So there > >> is no inherent need to support is_lock_free for alignment-issues > >> and there must be another good reason because for this is evaluated > >> at runtime. > > > More nonsense. Nothing in standard says that all objects of type > > std::atomic<T> are aligned in a way that reads and writes to those > > objects can be made lock free. > > You can't read. I did say: > 1. All complete types have a natural alignment. > 2. std::atomic<T> thereby has also a natural alignment. > 3. is_lock_free couldn't be dynamic because of runtime alignment > properties because C++ doesn't support unaligned acceses anyway. I understand very well what you write. It is just wrong. That "natural alignment" does not exist in C++. Quote from where you manufactured that misconception? Bald, groundless and wrong assertion in 1. is making also conclusions from it in 2. and 3. wrong and whole chain of your logic nonsense.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-17 11:23 +0100 |
| Message-ID | <qqr73k$l97$1@news.albasani.net> |
| In reply to | #69856 |
>> 1. All complete types have a natural alignment. >> 2. std::atomic<T> thereby has also a natural alignment. >> 3. is_lock_free couldn't be dynamic because of runtime alignment >> properties because C++ doesn't support unaligned acceses anyway. > I understand very well what you write. It is just wrong. > That "natural alignment" does not exist in C++. The implementation-defined natural alignment can be determined with alignof(). If you write your code so that it will satisfy this alignment on one platform and not another it is not portable. So each platform knows its own alignment-requirements and these are also maintained for the atomic-types. As long as you use proper alignment for your atomics there coudln't be any alignement-issues. So there's no need for the standad to mandate support for unaligned atomics through is_lock_free.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-11-17 03:22 -0800 |
| Message-ID | <6ab6d8ee-0bb4-4238-ae42-d70db528fec1@googlegroups.com> |
| In reply to | #69858 |
On Sunday, 17 November 2019 12:23:58 UTC+2, Bonita Montero wrote: > >> 1. All complete types have a natural alignment. > >> 2. std::atomic<T> thereby has also a natural alignment. > >> 3. is_lock_free couldn't be dynamic because of runtime alignment > >> properties because C++ doesn't support unaligned acceses anyway. > > > I understand very well what you write. It is just wrong. > > That "natural alignment" does not exist in C++. > > The implementation-defined natural alignment can be determined with > alignof(). Then read up on alignof in [basic.align]. It is returning alignment requirement for complete object (and not for subobject). > If you write your code so that it will satisfy this alignment > on one platform and not another it is not portable. Sure, I (as programmer) may not start life-time of whole object of type T in buffer that is more weakly aligned than alignof(T) requires. > So each platform > knows its own alignment-requirements and these are also maintained for > the atomic-types. You are mixing up. The alignof(T) is telling what it is requiring from programmers. It is not promising that subobjects of type T of composite objects are aligned by alignof(T). > As long as you use proper alignment for your atomics > there coudln't be any alignement-issues. So there's no need for the > standad to mandate support for unaligned atomics through is_lock_free. And here it is totally unclear who you address as "you". Are you addressing programmers, compilers, standards or whole reality that does not behave by your silly misconceptions?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-17 14:20 +0100 |
| Message-ID | <qqrhe9$1oq$1@news.albasani.net> |
| In reply to | #69860 |
>> The implementation-defined natural alignment can be determined with >> alignof(). > Then read up on alignof in [basic.align]. It is returning alignment > requirement for complete object (and not for subobject). I didn't talk about subobjects. >> So each platform >> knows its own alignment-requirements and these are also maintained for >> the atomic-types. > You are mixing up. The alignof(T) is telling what it is requiring > from programmers. It is not promising that subobjects of type T of > composite objects are aligned by alignof(T). Of course the compiler meets the requirements it also imposes on the programmer.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-11-17 06:39 -0800 |
| Message-ID | <669f64c5-28fc-427a-9151-57e6c2e08b27@googlegroups.com> |
| In reply to | #69862 |
On Sunday, 17 November 2019 15:20:21 UTC+2, Bonita Montero wrote: > >> The implementation-defined natural alignment can be determined with > >> alignof(). > > > Then read up on alignof in [basic.align]. It is returning alignment > > requirement for complete object (and not for subobject). > > I didn't talk about subobjects. Indeed why you wiggle away from those for whole week? Where it is written that atomic<T> is unsuitable to be type of subobject of other object? > > >> So each platform > >> knows its own alignment-requirements and these are also maintained for > >> the atomic-types. > > > You are mixing up. The alignof(T) is telling what it is requiring > > from programmers. It is not promising that subobjects of type T of > > composite objects are aligned by alignof(T). > > Of course the compiler meets the requirements it also imposes on the > programmer. Standard explicitly tells that the subobjects might be aligned differently than whole objects and now you say that these "of course" are required to be aligned by alignof and may not be aligned differently? :D I think you are just pretending to be so utterly bone-headed so I give up attempts of teaching you.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-17 15:49 +0100 |
| Message-ID | <qqrmmd$fsj$1@news.albasani.net> |
| In reply to | #69863 |
>> I didn't talk about subobjects. > Indeed why you wiggle away from those for whole week? That's what I wrote and where you responoded with subobjects-whatever: The implementation-defined natural alignment can be determined with alignof(). If you write your code so that it will satisfy this alignment on one platform and not another it is not portable. So each platform knows its own alignment-requirements and these are also maintained for the atomic-types. As long as you use proper alignment for your atomics there coudln't be any alignement-issues. So there's no need for the standad to mandate support for unaligned atomics through is_lock_free. Where did I talk about subobjects there? > Where it is written that atomic<T> is unsuitable to be type of subobject > of other object? Quote where Is said this. >> Of course the compiler meets the requirements it also imposes on the >> programmer. > Standard explicitly tells that the subobjects might be aligned > differently than whole objects and now you say that these "of course" > are required to be aligned by alignof and may not be aligned > differently? :D The standard says that all objects of complete types have a poper alignment.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-11-17 22:54 -0800 |
| Message-ID | <27be0974-6f5d-481a-a847-8956bb5c8780@googlegroups.com> |
| In reply to | #69864 |
On Sunday, 17 November 2019 16:49:59 UTC+2, Bonita Montero wrote: > > The standard says that all objects of complete types have a poper > alignment. That is bald, groundless and nonsensical assertion. All objects *must* have complete types in C++ program: "A program is ill-formed if the definition of any object gives the object an incomplete type."
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.c++
csiph-web