Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #87301
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Subject | Re: ???The pool of talented C++ developers is running dry??? |
| Newsgroups | comp.lang.c++ |
| References | (2 earlier) <tkdeht$8bb$1@gioia.aioe.org> <tkepas$15jv$1@dont-email.me> <tkfoch$695m$1@dont-email.me> <CYOaL.12305$eyq6.10545@fx03.iad> <tkgj53$8nkh$1@dont-email.me> |
| Message-ID | <CTRaL.31519$NeJ8.1285@fx09.iad> (permalink) |
| Organization | UsenetServer - www.usenetserver.com |
| Date | 2022-11-09 17:58 +0000 |
David Brown <david.brown@hesbynett.no> writes:
>On 09/11/2022 15:39, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 09/11/2022 00:39, Chris M. Thomasson wrote:
>>>> On 11/8/2022 3:29 AM, Juha Nieminen wrote:
>>>
>>>> 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.
>>
>> IFF the target architecture doesn't have a comprehensive set of
>> atomic access instructions, perhaps.
>>
>> ARMv8 LSE, for example, has individual instructions for most of the
>> gcc atomic intrinsics (e.g. __sync_fetch_and_add will generate a single
>> LDADD atomic instruction). The instructions support the common
>> arithmetic operations (add, or, etc).
>>
>> Before LSE, the ARMv8 implementations were built using the arm
>> LL/SC equivalent (load exclusive/store exclusive) instructions.
>
>
>You are more familiar with the details of these things than most people,
>so I hope you (or someone else) will correct me if my logic below is wrong.
>
>
>There's no problem when the target has a single unbreakable instruction
>for the action. And LL/SC are fine for atomic loads or stores of
>different sizes.
Here's the code generated by GCC for
q = __sync_fetch_and_add(&q, 1u);
Without LSE (atomics) support:
401034: 885ffc60 ldaxr w0, [x3]
401038: 11000401 add w1, w0, #0x1
40103c: 8804fc61 stlxr w4, w1, [x3]
c01040: 35ffffa4 cbnz w4, 401034 <main+0x34>
With LSE (atomics) support:
12c: b8e10001 ldaddal w1, w1, [x0]
>
>But LL/SC is not sufficient for read-modify-write sequences of a size
>larger than can be handled by a single atomic instruction.
>
>Imagine you have a processor that can atomically read or write an
>unsigned integer type "uint". Your sequence for "uint_inc" will be :
>
>retry:
> load link x = *p
> x++
> if (store conditional *p = x fails) goto retry
>
>
>If two processes try this, they can interleave and be started or stopped
>without trouble - the result will be an atomic increment.
>
>Now consider a double-sized type containing two "uint" fields:
>
>retry:
> load link x_lo = *p
> x_hi = *(p + 1)
> x_lo++
> if (!x_lo) x_hi++
> if (store conditional *p = x_lo fails) goto retry
> *(p + 1) = x_hi
For such sequences, one uses the LL/SC as a spinlock;
acquire the spinlock, perform the non-atomic operation
and release the spinlock. On uniprocessor systems,
alternate mechanisms like disabling interrupts are the
common solution.
Although in this case, using a wider type if available is a
better option.
>
>If the process executing this is stopped after the first write, and a
>second process is run that calls a similar function, then the new
>process will see a half-changed value for the object resulting in a
>corrupted object. Resumption of the first process will half-change the
>value again. Different combinations of using "store_conditional" on the
>two stores will result in similar problems.
>
>The only way to make a multi-unit RMW operation work is if other
>processes are /blocked/ from breaking in during the actual write
>sequence. Reads and the calculation can be re-retried, but not the
>writes - they must be made an unbreakable sequence. And that, in
>general, means a lock and OS support to ensure that the locking process
>gets to finish.
>
>
>The gcc implementation of atomic operations (larger than can be handled
>with a single instruction) uses simple user-space spin locks (the lock
>can be accessed atomically - with an LL/SC sequence, for the ARM).
>
>If one process tries to access the atomic while another process has the
>lock, it will spin - running a busy wait loop. As long as these
>processes are running on different cores, there's no problem with one
>core running a few rounds of a tight loop while another core does a
>quick load or store. Given that contention is rare and cores are often
>plentiful, this results in a very efficient atomic operation. But it
>can deadlock - a process could take the spin lock and then get
>descheduled by the OS, and other threads wanting the lock could be
>activated. If these fill up the cores (maybe you have multiple threads
>all using the same supposedly lock-free atomic structure), you are screwed.
This is a typical priority inheritance problem.
>
>And if you have only one core (like almost all microcontrollers), and
>the thread that has the lock is interrupted by an interrupt routine that
>wants to access the same atomic variable, you are /really/ screwed.
To be fair, the programmer should be aware of these issues and not
use mechanisms subject to deadlock. As noted above, the typical
solution is to disable interrupts during a critical section.
>
>It's very unlikely that you'll hit a problem, but it is possible.
Famous last words, indeed.
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