Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #87319
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: ???The pool of talented C++ developers is running dry??? |
| Date | 2022-11-10 12:53 -0800 |
| Organization | A noiseless patient Spider |
| Message-ID | <tkjocq$kaut$1@dont-email.me> (permalink) |
| References | (5 earlier) <tkh03q$a45v$3@dont-email.me> <diUaL.5684$BaF9.4221@fx39.iad> <tkie4g$h5am$1@dont-email.me> <tkjkqu$k10j$3@dont-email.me> <tkjnqt$k9i0$1@dont-email.me> |
On 11/10/2022 12:44 PM, David Brown wrote: > On 10/11/2022 20:53, Chris M. Thomasson wrote: >> 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 > > And it if is not, what is the point in allowing it if the locks don't work? > >> >> 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 > > Hash-based arrays of locks are as bad as a single lock for all atomics, > in that it does not work unless it is a proper OS lock. The larger your > array of locks, the lower your chances of problems, but it all comes > down to one thing - are your locks safe or not? Well, my multi-mutex uses std::mutex as elements of its vector of locks. It hashes an address into said table. So, it's only as good as the implementation of std::mutex... std::vector<std::mutex> m_locks; Fair enough?
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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