Please provide atomics for float64

[jech]

Please provide operations in sync/atomic for operating on values of type float64. Load, Store, Swap and CAS would be sufficient.

For obvious reasons, CAS should not do the NaN dance — it should just test for bitwise equality.

[randall77]

You can do these pretty easily with unsafe

func atomicLoadFloat64(x *float64) {
    return math.Float64frombits(atomic.LoadUint64((*uint64)(unsafe.Pointer(x))))
}

I don't really have a specific objection to adding them to sync/atomic. We already have Int64/Uint64 variants of the same operation. That said, we do have a general reluctance to add operations to the stdlib without some confidence that their frequency of use warrants it. Could you explain more about why you want these? What would you use them for?

[jech]

You can do these pretty easily with unsafe

I was actually looking at math.Float64bits, but yeah, I guess unsafe would work too.

I don't really have a specific objection to adding them to sync/atomic. We already have Int64/Uint64 variants of the same operation. That said, we do have a general reluctance to add operations to the stdlib without some confidence that their frequency of use warrants it. Could you explain more about why you want these? What would you use them for?

I'm uploading data at a fixed rate. I'm mainaining an exponential average of the current upload rate in a structure Estimator, and doing stuff like: func (e *Estimator) Allow(value int) bool { e.advance(time.Now()) if e.value <= 0 || value <= 0 || e.value+float64(value) <= e.target * e.seconds { return true } return false } ... func (e *AtomicEstimator) Allow(value int) bool { e.Lock() v := e.Estimator.Allow(value) e.Unlock() return v } Since this is called fairly often, and since the AtomicEstimator is a single shared data structure, I'm toying with the idea of a fast path that doesn't take the lock. (I haven't finished yet, so I cannot tell you whether it makes any difference in the profiles -- and, quite frankly, I'd be surprised if it did.) No big deal -- the standard library provides everything that's needed to simulate them, and at any rate I'll most likely stick to the locking implementation after I get a chance to do some profiling --, but their omission surprised me.

…

-- Juliusz

[randall77]

Ok, I'll close this then.
We can reopen if we find a more compelling use case.

[ianlancetaylor]

I think that we should not provide a floating point Cas that does not handle NaN correctly; since most processors don't provide such an instruction, I don't think we should provide the function at all.

[jech]

Closed #21996.

Then I suggest adding a pointer to math.Float64bits to the package docs.