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 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-10-03 04:14 +0200 |
| Message-ID | <thdghu$21vk3$1@dont-email.me> |
| In reply to | #86766 |
Am 02.10.2022 um 21:46 schrieb Chris M. Thomasson: > Using LL/SC can be tricky. You really need to isolate the reservation > granule... In essence, you're doing the same thing with CAS, but it's easier to use since it eliminates the need for DWCAS for lock-free stacks. >> But atomic increments, decrements, ands, ors or whatever >> ebulated with LL/SC is sometimes slower. > How many times do you spin on a SC failure before you get, pissed off? With atomic non-CAS operations you never spin.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-10-02 19:43 -0700 |
| Message-ID | <thdi9a$229n9$1@dont-email.me> |
| In reply to | #86773 |
On 10/2/2022 7:14 PM, Bonita Montero wrote: > Am 02.10.2022 um 21:46 schrieb Chris M. Thomasson: > >> Using LL/SC can be tricky. You really need to isolate the reservation >> granule... > > In essence, you're doing the same thing with CAS, but it's easier > to use since it eliminates the need for DWCAS for lock-free stacks. Iirc, there was a paper on LL/SC and the ABA problem. I am not sure if every implementation of LL/SC can get around it. Iirc, a LL/SC that will make a SC fail if anything reads and/or writes from/to the RG should definitely get around ABA. However, from experience, I would choose something like cmpxchg8b over LL/SC any day. >>> But atomic increments, decrements, ands, ors or whatever >>> ebulated with LL/SC is sometimes slower. > >> How many times do you spin on a SC failure before you get, pissed off? > > With atomic non-CAS operations you never spin. > > > I was referring to SC failing. Why did it fail? Spuriously? From a read into the reservation granule? If a CAS fails, we know it is because the actual values were different. The compare part failed. There is a way to attack CAS. Have a racing heard of threads setting the shared value to random values. The a poor thread trying to do a CAS to update a data-structure or something, just might fail a lot of times. So, when a CAS fails, well, it's different than when a SC fails...
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-10-02 19:48 -0700 |
| Message-ID | <thdihc$229n9$2@dont-email.me> |
| In reply to | #86774 |
On 10/2/2022 7:43 PM, Chris M. Thomasson wrote: > On 10/2/2022 7:14 PM, Bonita Montero wrote: >> Am 02.10.2022 um 21:46 schrieb Chris M. Thomasson: >> >>> Using LL/SC can be tricky. You really need to isolate the reservation >>> granule... >> >> In essence, you're doing the same thing with CAS, but it's easier >> to use since it eliminates the need for DWCAS for lock-free stacks. > > Iirc, there was a paper on LL/SC and the ABA problem. I am not sure if > every implementation of LL/SC can get around it. Iirc, a LL/SC that will > make a SC fail if anything reads and/or writes from/to the RG should > definitely get around ABA. However, from experience, I would choose > something like cmpxchg8b over LL/SC any day. > > >>>> But atomic increments, decrements, ands, ors or whatever >>>> ebulated with LL/SC is sometimes slower. >> >>> How many times do you spin on a SC failure before you get, pissed off? >> >> With atomic non-CAS operations you never spin. >> >> >> > > I was referring to SC failing. Why did it fail? Spuriously? From a read > into the reservation granule? If a CAS fails, we know it is because the > actual values were different. The compare part failed. There is a way to > attack CAS. Have a racing heard of threads setting the shared value to > random values. The a poor thread trying to do a CAS to update a > data-structure or something, just might fail a lot of times. > > So, when a CAS fails, well, it's different than when a SC fails... > Iirc, the "weak" CAS in C++ allows for spurious failures.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-10-03 04:53 +0200 |
| Message-ID | <thdir2$22h9k$1@dont-email.me> |
| In reply to | #86774 |
Am 03.10.2022 um 04:43 schrieb Chris M. Thomasson: > On 10/2/2022 7:14 PM, Bonita Montero wrote: >> Am 02.10.2022 um 21:46 schrieb Chris M. Thomasson: >> >>> Using LL/SC can be tricky. You really need to isolate the reservation >>> granule... >> >> In essence, you're doing the same thing with CAS, but it's easier >> to use since it eliminates the need for DWCAS for lock-free stacks. > > Iirc, there was a paper on LL/SC and the ABA problem. ... There's no ABA-problem with LL/SC'd stacks since you can detect if the word has changed to the same value. > I was referring to SC failing. Why did it fail? Spuriously? .. Only when the cacheline holding the word has been touched by another thread.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-10-02 19:58 -0700 |
| Message-ID | <thdj4l$229n9$3@dont-email.me> |
| In reply to | #86776 |
On 10/2/2022 7:53 PM, Bonita Montero wrote: > Am 03.10.2022 um 04:43 schrieb Chris M. Thomasson: >> On 10/2/2022 7:14 PM, Bonita Montero wrote: >>> Am 02.10.2022 um 21:46 schrieb Chris M. Thomasson: >>> >>>> Using LL/SC can be tricky. You really need to isolate the >>>> reservation granule... >>> >>> In essence, you're doing the same thing with CAS, but it's easier >>> to use since it eliminates the need for DWCAS for lock-free stacks. >> >> Iirc, there was a paper on LL/SC and the ABA problem. ... > > There's no ABA-problem with LL/SC'd stacks since you can detect if > the word has changed to the same value. Iirc, it depended on how the LL/SC was implemented, how sensitive it was to alterations in the reservation granule. >> I was referring to SC failing. Why did it fail? Spuriously? .. > > Only when the cacheline holding the word has been touched > by another thread. This would be the weak form of CAS wrt C++. A "true" RMW CAS will fail only when the condition (the compare part) fails. A bus lock might need to be used under heavy conditions. Scott knows about that.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-10-03 08:27 +0200 |
| Message-ID | <thdvc0$23quj$1@dont-email.me> |
| In reply to | #86777 |
Am 03.10.2022 um 04:58 schrieb Chris M. Thomasson: >> There's no ABA-problem with LL/SC'd stacks since you can detect if >> the word has changed to the same value. > Iirc, it depended on how the LL/SC was implemented, how > sensitive it was to alterations in the reservation granule. It may fail only if the cacheline has been evicted for other reasons than that the SC'd word changed.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-10-03 13:49 -0700 |
| Message-ID | <thfhru$2ahuv$1@dont-email.me> |
| In reply to | #86778 |
On 10/2/2022 11:27 PM, Bonita Montero wrote: > Am 03.10.2022 um 04:58 schrieb Chris M. Thomasson: > >>> There's no ABA-problem with LL/SC'd stacks since you can detect if >>> the word has changed to the same value. > >> Iirc, it depended on how the LL/SC was implemented, how >> sensitive it was to alterations in the reservation granule. > > It may fail only if the cacheline has been evicted for other > reasons than that the SC'd word changed. > > Reading/writing to the reservation granule (RG) can cause an issue. Iirc, the RG can be bigger than a l2 cacheline...
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-10-04 10:53 -0700 |
| Message-ID | <thhrva$2n5sd$2@dont-email.me> |
| In reply to | #86785 |
On 10/3/2022 1:49 PM, Chris M. Thomasson wrote: > On 10/2/2022 11:27 PM, Bonita Montero wrote: >> Am 03.10.2022 um 04:58 schrieb Chris M. Thomasson: >> >>>> There's no ABA-problem with LL/SC'd stacks since you can detect if >>>> the word has changed to the same value. >> >>> Iirc, it depended on how the LL/SC was implemented, how >>> sensitive it was to alterations in the reservation granule. >> >> It may fail only if the cacheline has been evicted for other >> reasons than that the SC'd word changed. >> >> > > Reading/writing to the reservation granule (RG) can cause an issue. > Iirc, the RG can be bigger than a l2 cacheline... > Iirc, a RG can be several contiguous L2 cachelines. So, working with LL/SC can be a bit tricky. One generally wants to align the memory on a natural RG boundary, and pad it up to the size of a RG. False sharing a RG is HORRIBLE! Really bad. Think live lock... Wrt CAS, I tend to focus on a single L2 cacheline. False sharing a L2 cacheline wrt pure RMW CAS, well, its definitely not ideal, but at least CAS's can complete... Humm...
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-10-02 12:44 -0700 |
| Message-ID | <thcpmt$1q2fa$2@dont-email.me> |
| In reply to | #86689 |
On 9/28/2022 2:11 PM, Scott Lurndal wrote: > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >> On 9/28/2022 12:32 AM, David Brown wrote: >>> On 27/09/2022 21:42, Chris M. Thomasson wrote: > >>>> Yes. Using an address based hashed locking scheme works just in case >>>> the arch does not support the direct CPU instruction(s) (think CAS vs >>>> LL/SC) for an atomic RMW operation. >>> >>> LL/SC /is/ a locking scheme - using a hardware lock. And neither CAS >>> nor LL/SC work for RMW or even plain write operations that are bigger >>> than the processor can handle in a single write action. >> >> Correct. Imvho, the hardware itself is a _lot_ more efficient at these >> types of things... Agreed in a sense? I actually prefer pessimistic CAS >> over optimistic primitives like LL/SC. Iirc, a LL/SC can fail just by >> reading from the reservation granule. Let alone writing to it... PPC had >> a special section in its docs that explain the possible issue of a live >> lock. Iirc, even CAS has some special logic in the processor that can >> actually assert a bus lock. > > When ARM was designing their 64-bit architecture (ARMv8) circa 2011/2, they only > provided a LL/SC equivalent (load-exclusive/store-exclusive). Their > architecture partners at the time quickly requested support for > real RMW atomics, which were added as part of the LSE (Large System ISA > Extensions). LDADD, LDCLR (and with complement), LDSET (or), LDEOR (xor), > LDSMAX (signed maximum), LDUMAX (unsigned maximum), LDSMIN, LDUMIN. > > The processor fabric forwards the operation to the point of coherency > (e.g. the L2/LLC) for cachable memory locations and to the endpoint for > uncachable memory locations (e.g. a PCIexpress or CXL endpoint). Oh yeah! I remember reading about this over on comp.arch a while back. I wonder if I can find the post. Thanks Scott. :^)
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-22 05:59 +0000 |
| Message-ID | <tggtkr$10rd$1@gioia.aioe.org> |
| In reply to | #86473 |
David Brown <david.brown@hesbynett.no> wrote: > If you use "volatile" when you mean "atomic", your code is wrong. Yeah. Some programmers might have mistakenly thought that 'volatile' means the same thing as "atomic", and thus "thread-safe". However, programmers who know what they are doing also know that it isn't anything like that. I think that the exact semantics of 'volatile' might be largely implementation-defined, but AFAIK in most if not all compilers (especially gcc and clang) it effectively acts as an optimization barrier. It tells the compiler "any access to this must never be optimized away, nor moved to happen somewhere else in the code". In other words, if you eg. write a loop where you read a 'volatile' ten times, then the compiler must generate code that reads it ten times, inside that exact loop and nowhere else. The compiler must not optimize it to one single read or completely away (because it doesn't see anything changing it). By far the most common (perhaps only) use of this is in embedded programming, especially on very small processors, where things like ports and CPU pins are mapped into RAM (which means that reading the same memory location may give different values at different times, and writing values there most definitely must never be optimized away). There's another useful use of 'volatile': In benchmarking. Run the code that's to be benchmarked, and then assign the return value to a volatile. This stops the compiler from optimizing the whole thing away because it sees that the result isn't being used for anything. (It might not have optimized it away in the first place, but assigning the result to a volatile makes sure of that.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-22 09:32 +0200 |
| Message-ID | <tgh333$233l1$1@dont-email.me> |
| In reply to | #86481 |
On 22/09/2022 07:59, Juha Nieminen wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> If you use "volatile" when you mean "atomic", your code is wrong.
>
> Yeah. Some programmers might have mistakenly thought that 'volatile'
> means the same thing as "atomic", and thus "thread-safe". However,
> programmers who know what they are doing also know that it isn't
> anything like that.
>
> I think that the exact semantics of 'volatile' might be largely
> implementation-defined, but AFAIK in most if not all compilers
> (especially gcc and clang) it effectively acts as an optimization
> barrier. It tells the compiler "any access to this must never be
> optimized away, nor moved to happen somewhere else in the code".
Yes. You can think of "volatile" as telling the compiler "there are
things you don't know about that mean you can't apply as-if
optimisations here".
The implementation-defined nature of volatile accesses is unavoidable.
If you have, say, a volatile write to a uint32_t variable then most
32-bit or 64-bit systems will implement it as a single write. A 16-bit
system will have to break it into two writes. An original Alpha would
do a 64-bit read, a modify, then a 64-bit write. Most systems will
attempt a single write even if the address is unaligned, others might
break it down or the hardware might cause a trap on the unaligned
access. Accesses to bitfields have multiple possible implementations.
All in all, there's a lot that can't be specified in the standards.
Then there are read-write-modify accesses such as "v++;" or "v |=
0x0100;". Some architectures can do these atomically, others would need
bus locks and interrupt disabling to be atomic.
(As an interesting aside here, in the C standards up to C17 only
described "access to volatile objects". Only in C17 did it change to
"volatile accesses", defining what was meant by using a
pointer-to-volatile cast to access data that had not been defined as
volatile. I don't know what the C++ standards say there - but I believe
that, as for C, every compiler handles volatile accesses as you might
expect.)
>
> In other words, if you eg. write a loop where you read a
> 'volatile' ten times, then the compiler must generate code that
> reads it ten times, inside that exact loop and nowhere else.
> The compiler must not optimize it to one single read or
> completely away (because it doesn't see anything changing it).
It can still unroll the loop. Similarly if you have :
volatile int v;
if (a) {
v = 1;
} else {
v = 2;
}
then the compiler can do:
int temp = a ? 1 : 2;
v = temp;
The run-time pattern of volatile accesses must match the "abstract
machine" exactly, but the pattern of the generated assembly need not.
>
> By far the most common (perhaps only) use of this is in embedded
> programming, especially on very small processors, where things
> like ports and CPU pins are mapped into RAM (which means that
> reading the same memory location may give different values at
> different times, and writing values there most definitely must
> never be optimized away).
Yes.
And for single-core processors (covering the great majority of
small-systems embedded programming), "volatile" is often sufficient in
many places where atomics would be needed in general. But you need to
be aware of its limitations here - it forms part of the solution, but
not necessarily all of it. (The gcc implementation of C11/C++11
atomics, at least in the gcc versions I have looked at, are dangerously
wrong for single core embedded systems.)
>
> There's another useful use of 'volatile': In benchmarking.
> Run the code that's to be benchmarked, and then assign the
> return value to a volatile. This stops the compiler from
> optimizing the whole thing away because it sees that the
> result isn't being used for anything. (It might not have
> optimized it away in the first place, but assigning the
> result to a volatile makes sure of that.)
Yes, that kind of use is convenient. You also have to ensure that the
calculation depends on a volatile variable, not just that the result is
written to one. It gives you a more self-contained test than reading an
starting input from the command line and printf'ing the result.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-09-21 15:42 +0000 |
| Message-ID | <tgfbcn$fq9$1@gioia.aioe.org> |
| In reply to | #86456 |
On Wed, 21 Sep 2022 15:24:01 +0200 David Brown <david.brown@hesbynett.no> wrote: >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. Also with some compilers the follow works: snprintf(mystr,some_max_len,"%s etc etc",mystr, etc etc) and with some it just produces garbage in mystr. Which is annoying as it saves a lot of mucking about with strcat when forced to use plain C.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-21 18:10 +0200 |
| Message-ID | <tgfd11$1rquq$1@dont-email.me> |
| In reply to | #86461 |
Am 21.09.2022 um 17:42 schrieb Muttley@dastardlyhq.com: > On Wed, 21 Sep 2022 15:24:01 +0200 > David Brown <david.brown@hesbynett.no> wrote: >> 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. > > Also with some compilers the follow works: > > snprintf(mystr,some_max_len,"%s etc etc",mystr, etc etc) > > and with some it just produces garbage in mystr. Which is annoying as > it saves a lot of mucking about with strcat when forced to use plain C. There's no real purpose for things like that so that it doesn't make sense to think about such things.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-09-21 16:19 +0000 |
| Message-ID | <tgfdjd$1l69$1@gioia.aioe.org> |
| In reply to | #86463 |
On Wed, 21 Sep 2022 18:10:32 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: >Am 21.09.2022 um 17:42 schrieb Muttley@dastardlyhq.com: >> On Wed, 21 Sep 2022 15:24:01 +0200 >> David Brown <david.brown@hesbynett.no> wrote: >>> 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. >> >> Also with some compilers the follow works: >> >> snprintf(mystr,some_max_len,"%s etc etc",mystr, etc etc) >> >> and with some it just produces garbage in mystr. Which is annoying as >> it saves a lot of mucking about with strcat when forced to use plain C. > >There's no real purpose for things like that so that it doesn't make >sense to think about such things. You don't need to keep demonstrating that you've never done any programming outside of your ivory tower and certainly not in C, we already know.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-21 18:27 +0200 |
| Message-ID | <tgfe0r$1ru2m$1@dont-email.me> |
| In reply to | #86465 |
Am 21.09.2022 um 18:19 schrieb Muttley@dastardlyhq.com: > On Wed, 21 Sep 2022 18:10:32 +0200 > Bonita Montero <Bonita.Montero@gmail.com> wrote: >> Am 21.09.2022 um 17:42 schrieb Muttley@dastardlyhq.com: >>> On Wed, 21 Sep 2022 15:24:01 +0200 >>> David Brown <david.brown@hesbynett.no> wrote: >>>> 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. >>> >>> Also with some compilers the follow works: >>> >>> snprintf(mystr,some_max_len,"%s etc etc",mystr, etc etc) >>> >>> and with some it just produces garbage in mystr. Which is annoying as >>> it saves a lot of mucking about with strcat when forced to use plain C. >> >> There's no real purpose for things like that so that it doesn't make >> sense to think about such things. > > You don't need to keep demonstrating that you've never done any programming > outside of your ivory tower and certainly not in C, we already know. > If you do things like the above you're in the highest ivory tower ever.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-09-23 14:47 +0000 |
| Message-ID | <tgkgtv$n8h$1@gioia.aioe.org> |
| In reply to | #86466 |
On Wed, 21 Sep 2022 18:27:30 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: >Am 21.09.2022 um 18:19 schrieb Muttley@dastardlyhq.com: >> On Wed, 21 Sep 2022 18:10:32 +0200 >> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Am 21.09.2022 um 17:42 schrieb Muttley@dastardlyhq.com: >>>> On Wed, 21 Sep 2022 15:24:01 +0200 >>>> David Brown <david.brown@hesbynett.no> wrote: >>>>> 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. >>>> >>>> Also with some compilers the follow works: >>>> >>>> snprintf(mystr,some_max_len,"%s etc etc",mystr, etc etc) >>>> >>>> and with some it just produces garbage in mystr. Which is annoying as >>>> it saves a lot of mucking about with strcat when forced to use plain C. >>> >>> There's no real purpose for things like that so that it doesn't make >>> sense to think about such things. >> >> You don't need to keep demonstrating that you've never done any programming >> outside of your ivory tower and certainly not in C, we already know. >> > >If you do things like the above you're in the highest ivory tower ever. Uh huh, whatever you say genius.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-21 16:12 +0000 |
| Message-ID | <tJGWK.637449$BKL8.221622@fx15.iad> |
| In reply to | #86461 |
Muttley@dastardlyhq.com writes:
>On Wed, 21 Sep 2022 15:24:01 +0200
>David Brown <david.brown@hesbynett.no> wrote:
>>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.
>
>Also with some compilers the follow works:
>
>snprintf(mystr,some_max_len,"%s etc etc",mystr, etc etc)
>
>and with some it just produces garbage in mystr. Which is annoying as it saves
>a lot of mucking about with strcat when forced to use plain C.
>
It seems fraught to store into the source string.
Better use of snprintf (and yes, this example will break
if the input buffer is too small; in this example, that
is guaranteed not to be the case). Easily fixed if necessary using
std::min(bplen,bytecount) in the subtract.
size_t
c_processor::format_insn(struct _op *opp,
c_environment *env,
mem_addr_t ip,
ulong afl, ulong bfl,
c_operand *opa, c_operand *opb,
c_operand *opc, bool symbolic,
char **bpp, size_t bplen)
{
size_t bytecount = 0;
char buf[10];
char *bp = *bpp;
bytecount = snprintf(bp, bplen, "[%1.1lu/%4.4lu]%s:%6.6llu: %4.4s ",
p_procnum, p_curtasknum,
env->print(buf, sizeof(buf)), ip, opp->op_name);
bplen -= bytecount, bp += bytecount;
if (!opp->op_noafbf) {
bytecount = snprintf(bp, bplen, "%2.2lu", afl);
bplen -= bytecount, bp += bytecount;
if (opp->op_bfhex) {
bytecount = snprintf(bp, bplen, "%2.2lx ", bfl);
bplen -= bytecount, bp += bytecount;
} else {
bytecount = snprintf(bp, bplen, "%2.2lu ", bfl);
bplen -= bytecount, bp += bytecount;
}
} else {
if (opp->op_opcode == OP_ACM) {
bytecount = snprintf(bp, bplen, "%2.2lx ", afl);
bplen -= bytecount, bp += bytecount;
}
}
if ((opp->op_operands > 0) && (opa != NULL)) {
bplen = opa->dump(&bp, bplen, symbolic);
*bp++ = ' ';
--bplen;
}
if ((opp->op_operands > 1) && (opb != NULL)) {
bplen = opb->dump(&bp, bplen, symbolic);
*bp++ = ' ';
--bplen;
}
if ((opp->op_operands > 2) && (opc != NULL)) {
bplen = opc->dump(&bp, bplen, symbolic);
*bp++ = ' ';
--bplen;
}
*bpp = bp;
return bplen;
}
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2022-09-23 19:52 +0200 |
| Message-ID | <tgkrp3$qc1$2@solani.org> |
| In reply to | #86456 |
Am 21.09.22 um 15:24 schrieb David Brown: > > There are no volatile versions > which could be used to ensure that something like an "memset" to wipe > memory would actually be run. Are you looking for C23 memset_explicit?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-24 16:25 +0200 |
| Message-ID | <tgn40b$309ud$2@dont-email.me> |
| In reply to | #86542 |
On 23/09/2022 19:52, Philipp Klaus Krause wrote: > Am 21.09.22 um 15:24 schrieb David Brown: > >> >> There are no volatile versions which could be used to ensure that >> something like an "memset" to wipe memory would actually be run. > Are you looking for C23 memset_explicit? > > Yes - although I'd forgotten the name. It will certainly solve one of the functions I see as missing.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-21 14:00 +0000 |
| Message-ID | <vOEWK.637442$BKL8.394357@fx15.iad> |
| In reply to | #86454 |
Juha Nieminen <nospam@thanks.invalid> writes: >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: I've always used memcpy. I've very seldom used any str* function other than strlen and once in a blue moon, strtok. I use snprintf in place of strcat, for instance.
[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