Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c++ > #86688

Re: Never use strncpy!

From "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups comp.lang.c++
Subject Re: Never use strncpy!
Date 2022-09-28 13:34 -0700
Organization A noiseless patient Spider
Message-ID <th2b5h$eg6k$1@dont-email.me> (permalink)
References (15 earlier) <tgth7s$3rvll$1@dont-email.me> <SBDYK.231093$51Rb.96992@fx45.iad> <tgv74b$3ilt$1@dont-email.me> <tgvjmu$4j86$1@dont-email.me> <th0t9s$alqp$1@dont-email.me>

Show all headers | View raw


On 9/28/2022 12:32 AM, David Brown wrote:
> On 27/09/2022 21:42, Chris M. Thomasson wrote:
>> On 9/27/2022 9:07 AM, David Brown wrote:
>>> On 27/09/2022 16:17, Scott Lurndal wrote:
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>> On 9/26/2022 4:39 AM, David Brown wrote:
>>>>
>>>>> // A RMW operation
>>>>> int
>>>>> fetch_add(
>>>>>      int& origin,
>>>>> ) {
>>>>>       hash_lock(&origin);
>>>>>       int result = origin;
>>>>>       origin = result + 1;
>>>>>       hash_unlock(&origin);
>>>>>       return result;
>>>>> }
>>>>> ________________________
>>>>>
>>>>> Okay, we are atomic. There are other ways to get this done.
>>>>>
>>>>> https://en.cppreference.com/w/cpp/atomic/atomic/fetch_add
>>>>
>>>> GCC has had built-ins to generate atomic accesses (e.g. 
>>>> __sync_fetch_and_add)
>>>> for many years now.
>>>>
>>>> On intel/amd these generate lock prefixes, on other architectures
>>>> with atomic support (e.g. ARMv8 LDADD, et alia) those instructions
>>>> will be generated.
>>>
>>> For more demanding cases - sizes larger than the hardware supports 
>>> directly, or read-write-modify on RISC - gcc uses a library that does 
>>> much what Chris has shown here.  The locks are simple busy-wait 
>>> user-space spin locks on an atomic flag, which are very efficient on 
>>> most systems (especially in the common case of no contention). 
>>> Unfortunately, this solution is worse than useless in some cases, 
>>> such as real-time systems and single-core systems.
>>>
>>
>> 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.


>> However, the locking emulation is most definitely, not ideal. Not 
>> lock-free, indeed. 
> 
> Processors can generally handle lock-free atomic access of a single 
> object of limited size - usually the natural width for the processor. 
> Some processors have instructions for double-width atomic accesses (such 
> as a double compare-and-swap).  And sometimes instruction sequences, 
> such as LL/SC with loops, are needed - especially for RMW.

Afaict, DWCAS is there to help get around the ABA problem ala IBM sysv 
appendix, oh shit, I forgot the appendix number. I used to know it, 
decades ago. I will try to find it.


> Lock-free algorithms beyond that are for specific data structures.  You 
> can't make lock-free atomic access to a 32 byte object.  You either have 
> to use locks (as will be done with a std::atomic<> for the type, or 
> using the C11 _Atomic qualifier).  If you want lock-free access, you 
> have to wrap it all up in a more advanced structure, using something 
> like a lock-free atomic pointer to the "current" version of the data 
> allocated on a heap.

Agreed. Although, I have created lock-free allocators that never used 
dynamic memory, believe it or not. Everything exists on threads stacks. 
And memory from thread A could be "freed" by another thread. I remember 
a project I had to do for a Quadros based system. Completely based on 
stacks. Wow, what a time.


>> Sorry about that non-sense David: Wrt the dangling comma. Forgot to 
>> introduce the addend for the fetch-add RMW operation.
>>
>> Shit happens. :^)
>>
> 
> That's just minor detail, so not a problem at all.

Thanks. :^)

Back to comp.lang.c++ | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web