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

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

Re: ???The pool of talented C++ developers is running dry???

Show all headers | View raw

On 11/10/2022 12:52 AM, David Brown wrote:
> On 09/11/2022 21:43, Scott Lurndal wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> On 11/9/2022 12:29 AM, David Brown wrote:
>>>> On 09/11/2022 00:39, Chris M. Thomasson wrote:
>>>>> On 11/8/2022 3:29 AM, Juha Nieminen wrote:
>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>>>>>>> You keep on adding features to the language which have unintuitive
>>>>>>> syntax and odd rules, and
>>>>>>> don't do much to increase the number of programs you can write
>>>>>>> quickly. So what happens?
>>>>>>> Theres not much motivation to learn these features until forced to
>>>>>>> do so. So codebases tend
>>>>>>> to be mainly legacy, and C++ programmers' skills fall behind.
>>>>>>
>>>>>> For the longest time I quite strongly disagreed with the claim that
>>>>>> C++ is
>>>>>> becoming too big and too complicated.
>>>>>>
>>>>>> However, C++20 has eroded this conviction of mine somewhat. C++23 is
>>>>>> eroding
>>>>>> it even more.
>>>>>>
>>>>>> C++11 felt like a big bunch of features that the language was in dire
>>>>>> need
>>>>>> of, and genuinely made programming easier. C++14 and C++17 fixed and
>>>>>> patched
>>>>>> many of the minor problems and defects that turned out to exist in
>>>>>> C++11,
>>>>>> so C++17 felt like "what C++11 should have been in the first place".
>>>>
>>>> I agree with that.
>>>>
>>>> A challenge for C++ is that even when a new and better feature is 
>>>> added,
>>>> the older and clumsier methods still have to be supported.  This also
>>>> means that syntax can be awkward because it can't conflict with 
>>>> existing
>>>> syntax, and the details get more complex all the time.
>>>>
>>>>>
>>>>> I was really excited and happy when C++ finally made atomics and
>>>>> membars part of the actual standard, C++11 iirc. Before that, I would
>>>>> have to code these things up in assembly language.
>>>>>
>>>>
>>>> Standard atomics would be great if they worked for my targets.  The gcc
>>>> implementations (and I haven't seen any others) for "advanced" use
>>>> (read-modify-write, or sizes larger than a standard register) is
>>>> completely broken for single-core systems, and even on multi-core
>>>> systems it is limited if you use thread priorities.  The trouble with
>>>> them is that no one has addressed the elephant in the room - in 
>>>> general,
>>>> you need OS support and locks to implement large atomics.
>>>
>>> Are you referring to double-width compare-and-swap (DWCAS)? C++ should
>>> be able to handle it directly using the processors instruction set. Say
>>> C++ on a modern 64 bit x64 system, well CMPXCHG16B should be used for a
>>> double word. Double word in the sense that they are two _contiguous_
>>> words. In other words, a lock-free CAS of a double word on a 64 bit x64
>>> should use CMPXCHG16B.
>>
>> David works with low-end embedded processors, as I understand it, with
>> limited and/or restricted instruction sets.
>>
> 
> Yes.
> 
> But the principle is the same on bigger systems too.  If your processor 
> can do a single-instruction 64-bit write, you see the problems for 
> atomics bigger than 64-bit.  If it can handle 128-bit writes, you see 
> the problems for atomics bigger than 128-bit.
> 
> Obviously the need for big atomics is much lower than the need for 
> smaller ones.  Once you have a DCAS, or LL/SC, you have covered most needs.
> 
> However, these alone will not give you read-modify-write operations on 
> anything bigger than you can handle with a single read (or more 
> importantly, with a single unbreakable write operation).  Anything where 
> the implementation is "use small atomics to get a spin lock, then do the 
> work" is /broken/.  It has a small but non-zero chance of failing in 
> general use on big multi-core systems.  On small single-core systems, it 
> is guaranteed broken from the outset.
> 
> The C++ (and C) language, standard library, common toolchains and 
> library implementations give the programmer the impression that they can 
> make atomics as they like.  You can write :
> 
>      std::atomic<std::array<int, 32>> xs;
> 
> and it looks like you have a big atomic object.  But it will not work - 
> you cannot rely on it.  It will /seem/ to work in all your testing, 
> because the chance of hitting a problem is small - but it can fail at 
> any time.

A rule of thumb... Imvho, always check the result of:

https://en.cppreference.com/w/cpp/atomic/atomic/is_lock_free

Just to be, sure... ;^) Fwiw, DWCAS is very different than DCAS. The 
latter can work on two non-contiguous words. The former only works with 
contiguous words. A main reason for DWCAS to exist in the first place is 
to be able to handle a lock-free stack. A pointer and an version count 
to combat the ABA problem. Although, there are many other interesting 
uses for DWCAS...

https://groups.google.com/g/comp.lang.c++/c/nUDtke-H1io/m/g87spoMUCgAJ


> The atomics that the programmer can use should either be absolutely 
> correct, guaranteed by design in all circumstances, or they should not 
> be compile-time errors when you try to use atomics that are too big, or 
> where the operations are too complex, for the implementation to guarantee.
> 
> It would be even better for the implementation to handle these 
> correctly.  That means OS support for /real/ locks, not fake 
> sort-of-works userland spin locks, but futexes or something like that 
> for big systems, and interrupt disabling for single-core 
> microcontrollers.  (Dual-core microcontrollers are an extra 
> complication.)  Common library implementations could rely on an extra 
> library or code for their "lock" and "unlock" calls - if they are not 
> provided, you at least have a link error.
> 

If the result of is_lock_free is not true, then you should really think 
about digging into how the locking is actually implemented. Hash based 
address locking is one simple way to do it. Fwiw, I created one called 
multi-mutex:

https://groups.google.com/g/comp.lang.c++/c/sV4WC_cBb9Q/m/Ti8LFyH4CgAJ

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

Thread

“The pool of talented C++ developers is running dry” Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-03 14:30 -0500
  Re: “The pool of talented C++ developers is running dry” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-03 13:03 -0700
    Re: “The pool of talented C++ developers is running dry” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-03 13:04 -0700
      Re: “The pool of talented C++ developers is running dry” Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-03 16:07 -0500
    Re: “The pool of talented C++ developers is running dry” Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-03 16:05 -0500
      Re: “The pool of talented C++ developers is running dry” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-03 14:25 -0700
        Re: “The pool of talented C++ developers is running dry” Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-05 14:12 -0500
          Re: “The pool of talented C++ developers is running dry” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-05 14:20 -0700
      Re: “The pool of talented C++ developers is running dry” Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-04 09:24 +0100
  Re: “The pool of talented C++ developers is running dry” Vir Campestris <vir.campestris@invalid.invalid> - 2022-11-05 21:42 +0000
  Re: “The pool of talented C++ developers is running dry” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-06 11:55 -0800
  Re: “The pool of talented C++ developers is running dry” Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-11-08 02:44 -0800
    Re: ???The pool of talented C++ developers is running dry??? Juha Nieminen <nospam@thanks.invalid> - 2022-11-08 11:29 +0000
      Re: ???The pool of talented C++ developers is running dry??? Öö Tiib <ootiib@hot.ee> - 2022-11-08 03:54 -0800
        Re: ???The pool of talented C++ developers is running dry??? Stuart Redmann <DerTopper@web.de> - 2022-11-08 14:26 +0100
          Re: ???The pool of talented C++ developers is running dry??? Öö Tiib <ootiib@hot.ee> - 2022-11-09 00:22 -0800
        Re: ???The pool of talented C++ developers is running dry??? Juha Nieminen <nospam@thanks.invalid> - 2022-11-08 15:16 +0000
      Re: ???The pool of talented C++ developers is running dry??? Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-08 14:52 +0100
      Re: ???The pool of talented C++ developers is running dry??? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2022-11-08 22:48 +0000
      Re: ???The pool of talented C++ developers is running dry??? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-08 15:39 -0800
        Re: ???The pool of talented C++ developers is running dry??? David Brown <david.brown@hesbynett.no> - 2022-11-09 09:29 +0100
          Re: ???The pool of talented C++ developers is running dry??? scott@slp53.sl.home (Scott Lurndal) - 2022-11-09 14:39 +0000
            Re: ???The pool of talented C++ developers is running dry??? David Brown <david.brown@hesbynett.no> - 2022-11-09 17:05 +0100
              Re: ???The pool of talented C++ developers is running dry??? scott@slp53.sl.home (Scott Lurndal) - 2022-11-09 17:58 +0000
          Re: ???The pool of talented C++ developers is running dry??? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-09 11:47 -0800
            Re: ???The pool of talented C++ developers is running dry??? scott@slp53.sl.home (Scott Lurndal) - 2022-11-09 20:43 +0000
              Re: ???The pool of talented C++ developers is running dry??? David Brown <david.brown@hesbynett.no> - 2022-11-10 09:52 +0100
                Re: ???The pool of talented C++ developers is running dry??? Michael S <already5chosen@yahoo.com> - 2022-11-10 03:07 -0800
                Re: ???The pool of talented C++ developers is running dry??? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-10 11:53 -0800
                Re: ???The pool of talented C++ developers is running dry??? David Brown <david.brown@hesbynett.no> - 2022-11-10 21:44 +0100
                Re: ???The pool of talented C++ developers is running dry??? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-10 12:53 -0800
                Re: ???The pool of talented C++ developers is running dry??? scott@slp53.sl.home (Scott Lurndal) - 2022-11-10 21:20 +0000
                Re: ???The pool of talented C++ developers is running dry??? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-10 13:23 -0800
                Re: ???The pool of talented C++ developers is running dry??? David Brown <david.brown@hesbynett.no> - 2022-11-11 08:10 +0100
                Re: ???The pool of talented C++ developers is running dry??? Öö Tiib <ootiib@hot.ee> - 2022-11-11 01:45 -0800
              Re: ???The pool of talented C++ developers is running dry??? Michael S <already5chosen@yahoo.com> - 2022-11-10 03:14 -0800
      Re: ???The pool of talented C++ developers is running         dry??? Sam <sam@email-scan.com> - 2022-11-09 07:59 -0500

csiph-web