On Wednesday, 23 August 2023 19:45:16 PDT Nate Eldredge wrote:
> On Wed, 23 Aug 2023, Thiago Macieira via Std-Discussion wrote:
> > From the point of view of implementations, the standard is the one that
> > needs to be fixed. Until we have per-instruction "suppress exception"
> > mode (on x86, that's only available with AVX512 and AVX10), atomic FP
> > operations would need to repeatedly save, update, and restore the FP
> > environment, which aren't trivial instructions. However, given that CPUs
> > usually don't have atomic FP operations anyway, implementations will
> > likely need to lock mutexes around the non-atomic ops, so the cost of
> > modifying the FP environment may be acceptable.
>
> std::atomic<float> and std::atomic<double> are lock-free on major
> implementations, so there's no mutex. Typically fetch_add and friends are
> implemented with a compare-exchange loop.

Oh, right, I hadn't thought of that. My bad, it was right there.

What this means, though, is that the cost of manipulating the floating point
environment in the processor state is non-negligible.

> LL/SC platforms like ARM could perhaps do better by just doing a
> floating-point add inside the LL/SC, but I don't think current
> implementations do this optimization.

Some architectures may limit which operations can be executed inside of an LL/
SC section. It's been well over a decade since I looked into this, but this
was one argument back in the day about using LL/SC to protect against ABA
problems.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering