Go's Atomic And/Or journey

go_atomic_and_or.md

Atomic.And/Or in Go

• Bitwise Atomic And/Or were missing from sync/atomic
• Users fallback to CAS, runtime used it too
• Required to reduce contention in hot code paths

// Before: racing to set a bit atomically
for {
    old := atomic.LoadUint32(&flags)
    if atomic.CompareAndSwapUint32(&flags, old, old|0x4) {
        break
    }
}

// After
atomic.OrUint32(&flags, 0x4)

Tracking issue: golang/go#61395

Implementation

Touches multiple parts of the Go language:

• internal runtime routines in assembly
• Public API
• Race detector
• Intrinsics

Architectures implemented, each one with it's subset of assembly

• amd64
• arm64
• arm386
• ppc64
• ppc64le
• s390x
• mips
• mipsle
• wasm
• powerpc
• loong64

Example:

Public APIs: https://go-review.googlesource.com/c/go/+/544455 Support for AMD64: https://go-review.googlesource.com/c/go/+/528315

Testing was done via qemu-system-static for more obscure arches. Emulator bugs tripping me off the entire time!

LLVM

Go's -race flag uses TSAN (ThreadSanitizer) from LLVM for race detection.

LLVM PR: llvm/llvm-project#65695

Precompiled syso CL from Cherry Mui (Google): https://go.dev/cl/543035

---

Result

• Atomic And/Or are native and intrinsified, 50-90% faster than CAS in highly contentious scenarios
• Merged into Go standard library for go 1.23/1.24
• Google Open Source Peer Bonus Award — 2024
• Now a maintainer of sync/atomic and several runtime packages

---

Other Contributions

https://go.mauri870.com

---

About Me

• Senior software Engineer at Elastic
• Shaping the future of OpenTelemetry
• Transition of Beats to native OpenTelemetry receivers
• Adapting Elastic Agent to an OpenTelemetry Collector
• GitHub: https://github.com/mauri870