Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #86454 > unrolled thread
| Started by | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| First post | 2022-09-21 10:04 +0000 |
| Last post | 2022-09-22 21:03 -0500 |
| Articles | 20 on this page of 90 — 16 participants |
Back to article view | Back to comp.lang.c++
Never use strncpy! Juha Nieminen <nospam@thanks.invalid> - 2022-09-21 10:04 +0000
Re: Never use strncpy! "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-09-21 15:06 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-21 15:24 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-21 15:30 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-21 19:20 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-21 19:33 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-21 23:14 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-22 04:40 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-22 08:56 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-22 12:02 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-23 13:23 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-23 13:49 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-23 15:25 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-23 16:03 +0200
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-09-23 14:34 +0000
Re: Never use strncpy! Michael S <already5chosen@yahoo.com> - 2022-09-23 08:19 -0700
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-09-23 17:57 +0000
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-23 18:36 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-24 16:22 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 16:25 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-24 17:09 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 17:14 +0200
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-26 17:34 -0700
Re: Never use strncpy! Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 07:53 +0000
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-26 10:21 +0200
Re: Never use strncpy! Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:34 +0000
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-26 13:39 +0200
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-26 17:47 -0700
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-09-27 14:17 +0000
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-27 18:07 +0200
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-27 12:42 -0700
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-28 09:32 +0200
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-28 13:34 -0700
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 21:11 +0000
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-01 06:26 +0200
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-10-01 17:01 +0000
Re: Never use strncpy! Michael S <already5chosen@yahoo.com> - 2022-10-02 15:32 -0700
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-10-03 14:01 +0000
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-03 13:49 -0700
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-02 12:46 -0700
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-03 04:14 +0200
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-02 19:43 -0700
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-02 19:48 -0700
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-03 04:53 +0200
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-02 19:58 -0700
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-03 08:27 +0200
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-03 13:49 -0700
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-04 10:53 -0700
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-02 12:44 -0700
Re: Never use strncpy! Juha Nieminen <nospam@thanks.invalid> - 2022-09-22 05:59 +0000
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-22 09:32 +0200
Re: Never use strncpy! Muttley@dastardlyhq.com - 2022-09-21 15:42 +0000
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-21 18:10 +0200
Re: Never use strncpy! Muttley@dastardlyhq.com - 2022-09-21 16:19 +0000
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-21 18:27 +0200
Re: Never use strncpy! Muttley@dastardlyhq.com - 2022-09-23 14:47 +0000
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-09-21 16:12 +0000
Re: Never use strncpy! Philipp Klaus Krause <pkk@spth.de> - 2022-09-23 19:52 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-24 16:25 +0200
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-09-21 14:00 +0000
Re: Never use strncpy! Juha Nieminen <nospam@thanks.invalid> - 2022-09-22 06:03 +0000
Re: Never use strncpy! Philipp Klaus Krause <pkk@spth.de> - 2022-09-23 19:50 +0200
Re: Never use strncpy! Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 07:54 +0000
Re: Never use strncpy! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-21 15:56 +0100
Re: Never use strncpy! Muttley@dastardlyhq.com - 2022-09-21 15:36 +0000
Re: Never use strncpy! Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-09-21 08:59 -0700
Re: Never use strncpy! Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-09-21 13:23 -0700
Re: Never use strncpy! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-21 21:49 +0100
Re: Never use strncpy! Richard Damon <Richard@Damon-Family.org> - 2022-09-21 19:18 -0400
Re: Never use strncpy! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-22 00:39 +0100
Re: Never use strncpy! Richard Damon <Richard@Damon-Family.org> - 2022-09-21 20:45 -0400
Re: Never use strncpy! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-21 18:00 -0700
Re: Never use strncpy! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-21 17:55 -0700
Re: Never use strncpy! Juha Nieminen <nospam@thanks.invalid> - 2022-09-22 06:09 +0000
Re: Never use strncpy! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-22 11:44 -0700
Re: Never use strncpy! Richard Damon <Richard@Damon-Family.org> - 2022-09-22 23:33 -0400
Re: Never use strncpy! Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-09-22 19:00 -0700
Re: Never use strncpy! Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-09-22 19:04 -0700
Re: Never use strncpy! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-22 22:49 -0700
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 11:38 +0200
Re: Never use strncpy! Muttley@dastardlyhq.com - 2022-09-24 09:43 +0000
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 11:59 +0200
Re: Never use strncpy! Richard Damon <Richard@Damon-Family.org> - 2022-09-24 06:27 -0400
Re: Never use strncpy! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-24 11:53 -0700
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 20:58 +0200
Re: Never use strncpy! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-21 16:01 -0700
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-22 09:37 +0200
Re: Never use strncpy! Manfred <noname@add.invalid> - 2022-10-01 01:24 +0200
Re: Never use strncpy! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-30 16:43 -0700
Re: Never use strncpy! Lynn McGuire <lynnmcguire5@gmail.com> - 2022-09-22 21:03 -0500
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-21 10:04 +0000 |
| Subject | Never use strncpy! |
| Message-ID | <tgenin$qc3$1@gioia.aioe.org> |
Well, *almost* never, at least. I always thought that std::strncpy() works exactly like std::strcpy(), except that it stops early if the specified count is reached. Turns out that I was gravely mistaken: "If, after copying the terminating null character from src, count is not reached, additional null characters are written to dest until the total of count characters have been written." This means that if you have, let's say, a 1 MB buffer into which you copy with std::strncpy() lots and lots of strings, the vast majority of them very short, expecting it to be efficient... turns out you'll be writing 1 MB worth of data every single time. Which will make the thing quite slow if you weren't aware of this. It's just better to do your own custom version of strncpy() that does what strncpy() should be doing, ie. just stop once the source string ends. I can't find any standard library (C or C++) function that does that, so you'll just have to write your own. (Luckily it's trivial to do.) And while you are at it, you might also want to fix this little problem: "If count is reached before the entire string src was copied, the resulting character array is not null-terminated." Perhaps return to the caller some value telling if the string was truncated.
[toc] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2022-09-21 15:06 +0200 |
| Message-ID | <tgf28n$1qr6t$1@dont-email.me> |
| In reply to | #86454 |
On 21 Sept 2022 12:04, Juha Nieminen wrote: > Well, *almost* never, at least. > > I always thought that std::strncpy() works exactly like std::strcpy(), > except that it stops early if the specified count is reached. Turns out > that I was gravely mistaken: > > "If, after copying the terminating null character from src, count is not > reached, additional null characters are written to dest until the total > of count characters have been written." > > This means that if you have, let's say, a 1 MB buffer into which you copy > with std::strncpy() lots and lots of strings, the vast majority of them > very short, expecting it to be efficient... turns out you'll be writing > 1 MB worth of data every single time. Which will make the thing quite > slow if you weren't aware of this. > > It's just better to do your own custom version of strncpy() that does > what strncpy() should be doing, ie. just stop once the source string > ends. > > I can't find any standard library (C or C++) function that does that, > so you'll just have to write your own. (Luckily it's trivial to do.) > > And while you are at it, you might also want to fix this little problem: > > "If count is reached before the entire string src was copied, the > resulting character array is not null-terminated." > > Perhaps return to the caller some value telling if the string was > truncated. Thank you. I was not aware. - Alf
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-21 15:24 +0200 |
| Message-ID | <tgf39h$1qua1$1@dont-email.me> |
| In reply to | #86454 |
On 21/09/2022 12:04, Juha Nieminen wrote: > Well, *almost* never, at least. > > I always thought that std::strncpy() works exactly like std::strcpy(), > except that it stops early if the specified count is reached. Turns out > that I was gravely mistaken: > > "If, after copying the terminating null character from src, count is not > reached, additional null characters are written to dest until the total > of count characters have been written." > > This means that if you have, let's say, a 1 MB buffer into which you copy > with std::strncpy() lots and lots of strings, the vast majority of them > very short, expecting it to be efficient... turns out you'll be writing > 1 MB worth of data every single time. Which will make the thing quite > slow if you weren't aware of this. > > It's just better to do your own custom version of strncpy() that does > what strncpy() should be doing, ie. just stop once the source string > ends. > > I can't find any standard library (C or C++) function that does that, > so you'll just have to write your own. (Luckily it's trivial to do.) > > And while you are at it, you might also want to fix this little problem: > > "If count is reached before the entire string src was copied, the > resulting character array is not null-terminated." > > Perhaps return to the caller some value telling if the string was > truncated. Several of the str* functions in the C standard library are downright silly. There are surprising inconsistencies (strncat guarantees a null-terminated result, strncpy does not), mostly useless return values, and missing functions (no strnlen). There are no volatile versions which could be used to ensure that something like an "memset" to wipe memory would actually be run. Then there are the myths and abuses that are common in real-world code, such as assumptions that "memcpy" runs forwards or works like "memmove". And there are no versions of the moves or copies that work on bigger block sizes - you are dependent on the quality of the compiler to figure out when larger sizes can be used. Good compilers can optimise some of this - if you have several "strcat" calls in a row, gcc can remember the length of each cat as a short-cut for the next one. It can sometimes inline memcpy, and other functions, giving better results. Poorer compilers implement these as external functions in a DLL, with correspondingly bad performance on small strings or memory blocks. The solution, of course, is a selection of non-standard additional string and memory functions that exist in some C libraries and not others, and sometimes have the same name but different functionality in different libraries. Oh, and there's the Annex K "bounds-checking" functions that MS pushed into the C standards that neither they nor anyone else implements, and no one would use even if they /were/ implemented.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-21 15:30 +0200 |
| Message-ID | <tgf3l1$1qu51$3@dont-email.me> |
| In reply to | #86456 |
Am 21.09.2022 um 15:24 schrieb David Brown: > Several of the str* functions in the C standard library are downright > silly. There are surprising inconsistencies (strncat guarantees a > null-terminated result, strncpy does not), mostly useless return values, > and missing functions (no strnlen). There are no volatile versions > which could be used to ensure that something like an "memset" to wipe > memory would actually be run. ... volatile ist mostly deprecated. atomics are used most of the time where you used volatiles before. And memcpy() memset don't need any behaviour like volatile or atomics since you could add memory barriers and you geet all you need.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-21 19:20 +0200 |
| Message-ID | <tgfh5a$1s7n1$1@dont-email.me> |
| In reply to | #86457 |
On 21/09/2022 15:30, Bonita Montero wrote: > Am 21.09.2022 um 15:24 schrieb David Brown: > >> Several of the str* functions in the C standard library are downright >> silly. There are surprising inconsistencies (strncat guarantees a >> null-terminated result, strncpy does not), mostly useless return >> values, and missing functions (no strnlen). There are no volatile >> versions which could be used to ensure that something like an "memset" >> to wipe memory would actually be run. ... > > volatile ist mostly deprecated. Volatile is not deprecated at all. Overly complex expressions involving volatile were deprecated in C++20 as their semantics were unclear. > atomics are used most of the time > where you used volatiles before. Complete nonsense. Volatile accesses and atomics are different things, for different purposes. > And memcpy() memset don't need > any behaviour like volatile or atomics since you could add memory > barriers and you geet all you need. > Following a memcpy() or memset() with a memory barrier (a relaxed order full fence) is certainly a possibility. But such fences can be a lot more expensive than using volatile writes.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-21 19:33 +0200 |
| Message-ID | <tgfhrv$1s8i7$1@dont-email.me> |
| In reply to | #86467 |
Am 21.09.2022 um 19:20 schrieb David Brown: > On 21/09/2022 15:30, Bonita Montero wrote: >> Am 21.09.2022 um 15:24 schrieb David Brown: >> >>> Several of the str* functions in the C standard library are downright >>> silly. There are surprising inconsistencies (strncat guarantees a >>> null-terminated result, strncpy does not), mostly useless return >>> values, and missing functions (no strnlen). There are no volatile >>> versions which could be used to ensure that something like an >>> "memset" to wipe memory would actually be run. ... >> >> volatile ist mostly deprecated. > > Volatile is not deprecated at all. Overly complex expressions involving > volatile were deprecated in C++20 as their semantics were unclear. The semantics of volatile has been reduced with C++20: https://en.cppreference.com/w/cpp/language/cv >> atomics are used most of the time >> where you used volatiles before. > > Complete nonsense. Volatile accesses and atomics are different things, > for different purposes. Before C++11 volatile were partitially used where today you use atomics. But the whole semantics were platform-specific. F.e. there's a mode of MSVC where volatile reads have acquire semantics and volatile writes have release semantics. > Following a memcpy() or memset() with a memory barrier (a relaxed order > full fence) is certainly a possibility. But such fences can be a lot > more expensive than using volatile writes. volatile writes can't be substituted with fences.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-21 23:14 +0200 |
| Message-ID | <tgfus6$1tinp$1@dont-email.me> |
| In reply to | #86468 |
On 21/09/2022 19:33, Bonita Montero wrote: > Am 21.09.2022 um 19:20 schrieb David Brown: >> On 21/09/2022 15:30, Bonita Montero wrote: >>> Am 21.09.2022 um 15:24 schrieb David Brown: >>> >>>> Several of the str* functions in the C standard library are >>>> downright silly. There are surprising inconsistencies (strncat >>>> guarantees a null-terminated result, strncpy does not), mostly >>>> useless return values, and missing functions (no strnlen). There >>>> are no volatile versions which could be used to ensure that >>>> something like an "memset" to wipe memory would actually be run. ... >>> >>> volatile ist mostly deprecated. >> >> Volatile is not deprecated at all. Overly complex expressions >> involving volatile were deprecated in C++20 as their semantics were >> unclear. > > The semantics of volatile has been reduced with C++20: > https://en.cppreference.com/w/cpp/language/cv No, the page there says - as I said - that some uses of volatile in complex expressions were deprecated in C++20. > >>> atomics are used most of the time >>> where you used volatiles before. >> >> Complete nonsense. Volatile accesses and atomics are different >> things, for different purposes. > > Before C++11 volatile were partitially used where today you use atomics. If you used "volatile" thinking you got the effects of atomic access, you were wrong. Prior to C++11 (and C11), C and C++ did not have any concept of multiple threads - they did not have any need of "atomic" accesses in the language. People who write OS's and similar low-level code needed to implement atomics for the system, and "volatile" was /part/ of those implementations. People writing code for such OS's and using atomics, used the OS's functions, classes, and macros. If you use "volatile" when you mean "atomic", your code is wrong. If you use "atomic" when you mean "volatile", your code will probably work but will be much less efficient. "volatile atomic" is an extremely common combination. > But the whole semantics were platform-specific. F.e. there's a mode of > MSVC where volatile reads have acquire semantics and volatile writes > have release semantics. > The details of volatile accesses are implementation-dependent, by necessity. And an implementation is allowed to make them stronger - though doing so is going to be inefficient and encourage misconceptions and unwarranted assumptions. >> Following a memcpy() or memset() with a memory barrier (a relaxed >> order full fence) is certainly a possibility. But such fences can be >> a lot more expensive than using volatile writes. > > volatile writes can't be substituted with fences. > A fence implies a memory barrier - writes that are logically part of the source code must be completed before the barrier completes. That is part of why you have fences.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-22 04:40 +0200 |
| Message-ID | <tgghtv$21stj$1@dont-email.me> |
| In reply to | #86473 |
Am 21.09.2022 um 23:14 schrieb David Brown: >> Before C++11 volatile were partitially used where today you use atomics. > If you used "volatile" thinking you got the effects of atomic access, > you were wrong. ... No, you could use volatile in an implementation-defined way and it did partitially the same like atomic. >>> Following a memcpy() or memset() with a memory barrier (a relaxed >>> order full fence) is certainly a possibility. But such fences can >>> be a lot more expensive than using volatile writes. >> volatile writes can't be substituted with fences. > A fence implies a memory barrier - ... It's a different word for the same thing.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-22 08:56 +0200 |
| Message-ID | <tgh0ul$22ufh$1@dont-email.me> |
| In reply to | #86480 |
On 22/09/2022 04:40, Bonita Montero wrote: > Am 21.09.2022 um 23:14 schrieb David Brown: > >>> Before C++11 volatile were partitially used where today you use atomics. > >> If you used "volatile" thinking you got the effects of atomic access, >> you were wrong. ... > > No, you could use volatile in an implementation-defined way and it did > partitially the same like atomic. > What do you think "volatile" does, as a qualifier for accesses? What do you think "atomic" means - both in terms of what the C and C++ standards say, and what the term means more generally in programming? There is a degree of overlap, but they are not the same thing. >>>> Following a memcpy() or memset() with a memory barrier (a relaxed >>>> order full fence) is certainly a possibility. But such fences can >>>> be a lot more expensive than using volatile writes. > >>> volatile writes can't be substituted with fences. > >> A fence implies a memory barrier - ... > > It's a different word for the same thing. > No, they are different things. Atomic fences are about synchronisation between different threads - they ensure that threads running on different cores see a consistent picture of the relevant data in memory. Memory barriers are about ordering of the /local/ view of memory reads and writes.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-22 12:02 +0200 |
| Message-ID | <tghbql$23qfo$1@dont-email.me> |
| In reply to | #86485 |
Am 22.09.2022 um 08:56 schrieb David Brown: > What do you think "volatile" does, as a qualifier for accesses? A volatile read or write is usually at least the same as a read or write through a memory_order relaxed. So there are some guarantees you can rely on. > No, they are different things. Atomic fences are about synchronisation > between different threads - they ensure that threads running on > different cores see a consistent picture of the relevant data in memory. > Memory barriers are about ordering of the /local/ view of memory reads > and writes. Fences and barriers mean the same. A fence or barrier makes that changes from a foreign thread become visible to another thread or changes from a thread become visible for other threads.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-23 13:23 +0200 |
| Message-ID | <tgk4vu$2gu8f$1@dont-email.me> |
| In reply to | #86490 |
On 22/09/2022 12:02, Bonita Montero wrote: > Am 22.09.2022 um 08:56 schrieb David Brown: > >> What do you think "volatile" does, as a qualifier for accesses? > > A volatile read or write is usually at least the same as a read or > write through a memory_order relaxed. So there are some guarantees > you can rely on. The key point of an atomic access, above all else, is that it is an all-or-nothing access. If one thread writes to an atomic object, and another thread reads it, then the reading thread will see either the complete old data or the complete new data. "Volatile" does not give you that guarantee. The key points regarding volatile accesses is that the compiler cannot assume it knows about the way the target memory is used - it may be read or written independently of the program code, and that the accesses are "observable behaviour". Thus every volatile access must be done exactly as it is in the "abstract machine" that defines the language - with the same values, same number of accesses, same order of accesses in respect to other volatile accesses. "Atomic" does not have those semantics. The compiler can combine two relaxed atomic writes to one. It can do some re-ordering regarding atomics and normal accesses, and even across volatile accesses. (For atomic memory access stricter than "relaxed", there are more restrictions on ordering.) This is why the C11 "atomic_store" and "atomic_load" functions take a pointer to volatile atomic as their parameter, not a pointer to atomic. > >> No, they are different things. Atomic fences are about >> synchronisation between different threads - they ensure that threads >> running on different cores see a consistent picture of the relevant >> data in memory. Memory barriers are about ordering of the /local/ >> view of memory reads and writes. > > Fences and barriers mean the same. A fence or barrier makes that changes > from a foreign thread become visible to another thread or changes from a > thread become visible for other threads. > In the C standards (I refer to them as they are simpler and clearer than the C++ standards, but the memory model is the same) say that an "atomic_thread_fence(memory_order_relaxed)" has no effect. This is rather different from a memory barrier, which requires compiler-specific extensions and which can be viewed roughly as a kind of "cache flush" in which the "cache" is the processor registers along with any information the compiler knows about any objects. Again, the non-relaxed fences will likely have a memory barrier effect in practice - but they do so at a significantly higher cost than a memory barrier.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-23 13:49 +0200 |
| Message-ID | <tgk6er$2h1tg$1@dont-email.me> |
| In reply to | #86525 |
Am 23.09.2022 um 13:23 schrieb David Brown: > The key point of an atomic access, above all else, is that it is an > all-or-nothing access. If one thread writes to an atomic object, and > another thread reads it, then the reading thread will see either the > complete old data or the complete new data. Although it is possible no one actually uses atomics for non-native types. And for native types what I said holds true against volatiles. > "Atomic" does not have those semantics. The compiler can combine two > relaxed atomic writes to one. Cite the standard. > In the C standards (I refer to them as they are simpler and clearer than > the C++ standards, but the memory model is the same) say that an > "atomic_thread_fence(memory_order_relaxed)" has no effect. This is > rather different from a memory barrier, which requires compiler-specific > extensions and which can be viewed roughly as a kind of "cache flush" in > which the "cache" is the processor registers along with any information > the compiler knows about any objects. That's pettifogging since no one uses fences which actually won't work.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-23 15:25 +0200 |
| Message-ID | <tgkc46$2hhg9$1@dont-email.me> |
| In reply to | #86529 |
On 23/09/2022 13:49, Bonita Montero wrote: > Am 23.09.2022 um 13:23 schrieb David Brown: > >> The key point of an atomic access, above all else, is that it is an >> all-or-nothing access. If one thread writes to an atomic object, and >> another thread reads it, then the reading thread will see either the >> complete old data or the complete new data. > > Although it is possible no one actually uses atomics for non-native > types. And for native types what I said holds true against volatiles. > No. >> "Atomic" does not have those semantics. The compiler can combine two >> relaxed atomic writes to one. > > Cite the standard. > "As if" rule. >> In the C standards (I refer to them as they are simpler and clearer >> than the C++ standards, but the memory model is the same) say that an >> "atomic_thread_fence(memory_order_relaxed)" has no effect. This is >> rather different from a memory barrier, which requires >> compiler-specific extensions and which can be viewed roughly as a kind >> of "cache flush" in which the "cache" is the processor registers along >> with any information the compiler knows about any objects. > > That's pettifogging since no one uses fences which actually won't work. > They /do/ work - they just do what they are supposed to do, not what you think they should do.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-23 16:03 +0200 |
| Message-ID | <tgkeah$2hnjc$1@dont-email.me> |
| In reply to | #86531 |
Am 23.09.2022 um 15:25 schrieb David Brown: > On 23/09/2022 13:49, Bonita Montero wrote: >> Am 23.09.2022 um 13:23 schrieb David Brown: >> >>> The key point of an atomic access, above all else, is that it is an >>> all-or-nothing access. If one thread writes to an atomic object, and >>> another thread reads it, then the reading thread will see either the >>> complete old data or the complete new data. >> >> Although it is possible no one actually uses atomics for non-native >> types. And for native types what I said holds true against volatiles. >> > > No. If you use non-native types with atomics they use STM, and that's really slow. That's while no one uses atomic for non-native types. > >>> "Atomic" does not have those semantics. The compiler can combine two >>> relaxed atomic writes to one. >> >> Cite the standard. >> > > "As if" rule. > >>> In the C standards (I refer to them as they are simpler and clearer >>> than the C++ standards, but the memory model is the same) say that an >>> "atomic_thread_fence(memory_order_relaxed)" has no effect. This is >>> rather different from a memory barrier, which requires >>> compiler-specific extensions and which can be viewed roughly as a >>> kind of "cache flush" in which the "cache" is the processor registers >>> along with any information the compiler knows about any objects. >> >> That's pettifogging since no one uses fences which actually won't work. >> > > They /do/ work - they just do what they are supposed to do, not what you > think they should do. No, they have actually no effect.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-23 14:34 +0000 |
| Message-ID | <LtjXK.60745$R_o7.56515@fx33.iad> |
| In reply to | #86534 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >Am 23.09.2022 um 15:25 schrieb David Brown: >> They [memory barriers] /do/ work - they just do what they are supposed to do, not what you >> think they should do. > >No, they have actually no effect. If that were the case, then there would be no need for memory barrier instructions, right? So why are they present in all architectures (x86, arm, mips, ppc, ia64?) Hint: because they actually _do_ have an effect, moreso in arm/mips/ppc than in x86, but they are actually required in x86 as well; I recall a linux kernel bug from a decade ago in the TCP stack related to skb management where a missing memory barrier caused all kinds of havoc even in the soi disant 'strongly-ordered' x86 memory model.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2022-09-23 08:19 -0700 |
| Message-ID | <ee848bc0-e0d3-4d2e-bf9c-7feebd35c333n@googlegroups.com> |
| In reply to | #86536 |
On Friday, September 23, 2022 at 5:34:36 PM UTC+3, Scott Lurndal wrote: > Bonita Montero <Bonita....@gmail.com> writes: > >Am 23.09.2022 um 15:25 schrieb David Brown: > >> They [memory barriers] /do/ work - they just do what they are supposed to do, not what you > >> think they should do. > > > >No, they have actually no effect. > If that were the case, then there would be no need for memory > barrier instructions, right? > > So why are they present in all architectures (x86, arm, mips, ppc, ia64?) > > Hint: because they actually _do_ have an effect, moreso in arm/mips/ppc > than in x86, Actually, less so on MIPS than on x86. On MIPS, I think, memory barriers needed only in code that mixes normal, ie. write-back cached, memory accesses (WB) with special I/O-type accesses like uncached (UC) and especially write-combined (WC). On x86 it's to the main reason for barriers, too, but there are subtle cases where MB is needed on pure WB areas as well. That's because x86 (and SPARC) default memory ordering is TCO rather than SC. However in practice on x86 WB areas people normally use implied barriers that are present in all RMW and CAS instructions with LOCK prefix. > but they are actually required in x86 as well; I recall a > linux kernel bug from a decade ago in the TCP stack related to skb > management where a missing memory barrier caused all kinds of havoc > even in the soi disant 'strongly-ordered' x86 memory model.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-23 17:57 +0000 |
| Message-ID | <4smXK.507376$iiS8.179792@fx17.iad> |
| In reply to | #86538 |
Michael S <already5chosen@yahoo.com> writes: >On Friday, September 23, 2022 at 5:34:36 PM UTC+3, Scott Lurndal wrote: >> Bonita Montero <Bonita....@gmail.com> writes: >> >Am 23.09.2022 um 15:25 schrieb David Brown: >> >> They [memory barriers] /do/ work - they just do what they are supposed to do, not what you >> >> think they should do. >> > >> >No, they have actually no effect. >> If that were the case, then there would be no need for memory >> barrier instructions, right? >> >> So why are they present in all architectures (x86, arm, mips, ppc, ia64?) >> >> Hint: because they actually _do_ have an effect, moreso in arm/mips/ppc >> than in x86, > >Actually, less so on MIPS than on x86. >On MIPS, I think, memory barriers needed only in code that mixes normal, >ie. write-back cached, memory accesses (WB) with special I/O-type accesses >like uncached (UC) and especially write-combined (WC). I was thinking specifically of kseg 0/1 aliases, which are uncached. >On x86 it's to the main reason for barriers, too, but there are subtle cases >where MB is needed on pure WB areas as well. >That's because x86 (and SPARC) default memory ordering is TCO rather than SC. >However in practice on x86 WB areas people normally use implied >barriers that are present in all RMW and CAS instructions with LOCK prefix. I missed Alpha in the list above, many of the alpha architects and engineers ended up at Cavium designing their version of MIPS processors.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-23 18:36 +0200 |
| Message-ID | <tgkn9l$2j447$1@dont-email.me> |
| In reply to | #86536 |
Am 23.09.2022 um 16:34 schrieb Scott Lurndal: > Bonita Montero <Bonita.Montero@gmail.com> writes: >> Am 23.09.2022 um 15:25 schrieb David Brown: > >>> They [memory barriers] /do/ work - they just do what they are supposed to do, not what you >>> think they should do. >> >> No, they have actually no effect. > > If that were the case, then there would be no need for memory > barrier instructions, right? Read what I said in the context !
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-24 16:22 +0200 |
| Message-ID | <tgn3ri$309ud$1@dont-email.me> |
| In reply to | #86534 |
On 23/09/2022 16:03, Bonita Montero wrote: > Am 23.09.2022 um 15:25 schrieb David Brown: >> On 23/09/2022 13:49, Bonita Montero wrote: >>> Am 23.09.2022 um 13:23 schrieb David Brown: >>> >>>> The key point of an atomic access, above all else, is that it is an >>>> all-or-nothing access. If one thread writes to an atomic object, >>>> and another thread reads it, then the reading thread will see either >>>> the complete old data or the complete new data. >>> >>> Although it is possible no one actually uses atomics for non-native >>> types. And for native types what I said holds true against volatiles. >>> >> >> No. > > If you use non-native types with atomics they use STM, and that's > really slow. That's while no one uses atomic for non-native types. There are a number of ways to implement atomics that are larger than a single bus operation can handle, or that involve multiple bus operations. Different processor types have different solutions, and some are optimised or limited to particular setups (such as single writer, single processor, etc.). Some processors can handle atomic accesses for sizes that are bigger than native C/C++ types (such as 128-bit accesses). Some cannot handle atomic writes for the bigger native types. And non-aligned accesses might be supported for volatile accesses, while not being atomic. In summary - you are making so many assumptions it is easiest just to say you are wrong. > >> >>>> "Atomic" does not have those semantics. The compiler can combine >>>> two relaxed atomic writes to one. >>> >>> Cite the standard. >>> >> >> "As if" rule. >> >>>> In the C standards (I refer to them as they are simpler and clearer >>>> than the C++ standards, but the memory model is the same) say that >>>> an "atomic_thread_fence(memory_order_relaxed)" has no effect. This >>>> is rather different from a memory barrier, which requires >>>> compiler-specific extensions and which can be viewed roughly as a >>>> kind of "cache flush" in which the "cache" is the processor >>>> registers along with any information the compiler knows about any >>>> objects. >>> >>> That's pettifogging since no one uses fences which actually won't work. >>> >> >> They /do/ work - they just do what they are supposed to do, not what >> you think they should do. > > No, they have actually no effect. > Perhaps some of your misconceptions are valid within your limited little world of x86 programming on Windows with MSVC. There is a wider world out there, and even if you never enter it, please stop making posts in a general C++ newsgroup full of invalid assumptions that only applies to such a limited subset of C++.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-24 16:25 +0200 |
| Message-ID | <tgn40n$30a4s$1@dont-email.me> |
| In reply to | #86554 |
Am 24.09.2022 um 16:22 schrieb David Brown: > There are a number of ways to implement atomics that are larger than > a single bus operation can handle, or that involve multiple bus > operations. ... It's always done by STM, and that's slow. > Perhaps some of your misconceptions are valid within your limited little > world of x86 programming on Windows with MSVC. There is a wider world > out there, and even if you never enter it, please stop making posts in a > general C++ newsgroup full of invalid assumptions that only applies to > such a limited subset of C++. I was referring to what you said and you forgot what you said.
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.lang.c++
csiph-web