C++ Logo

std-discussion

Advanced search

Re: Generalized atomic updates

From: Nate Eldredge <nate_at_[hidden]>
Date: Wed, 8 May 2024 16:28:26 -0600 (MDT)
On Wed, 8 May 2024, Chris Ryan via Std-Discussion wrote:

> IMHO atomics should only be for near intrinsic types/operations.

Agreed. But on an LL/SC architecture, every ALU instruction, or
sufficiently short sequence of them, is effectively available as an atomic
RMW intrinsic. I'm wondering if there is a way to expose this for use by
C++ programmers, while maintaining compatibility with machines that don't
have it. Currently if you want to access this functionality, you have to
drop to assembly language.

> Anything larger is a programming paradigm for exclusivity or a
> synchronization mechanisms that the user should write manually
> themselves so they will know and understand that there is
> potentially long lockout and be able to tune as appropriate.

Again, agreed. I don't think my imagined fetch_update() *should* be used
for "larger" operations that would compile into more than a couple of
instructions. But since we can't define that restriction precisely, it
might be better than nothing to have an implementation that is
sub-optimal, but still functions, when used "inappropriately".

> No hand holding.

Right. My main goal here isn't to provide a convenience feature, it's to
expose hardware functionality, which is the whole point of std::atomic as
I see it. That's generally going to be a footgun, just like most of
std::atomic already is, and here I just want to see if it's possible to
give it enough of a safety catch to be acceptable as part of C++.

-- 
Nate Eldredge
nate_at_[hidden]

Received on 2024-05-08 22:28:34