std.sync.atomic: extended atomic helper functions

[kprotty]

• generic Atomic(T) wrapper replacing atomic.Int and atomic.Bool
• Bitwise atomic intrinsics when Atomic(T) is an Integer
• No redundant specification of type as seen in builtins atomic functions
• fetchXX() ops instead of generic atomicRmw for C11 consistency
• contains compilerFence() and spinLoopHint()

[LemonBoy]

We already have atomic wrappers for ints and bools. That approach is much safer than taking raw pointers as it prevents you from mixing atomic and non-atomic ops.

[kprotty]

@LemonBoy atomic int and bool dont contain cmpxchg abstractions + there aren't any such wrappers for atomic pointers/enums/floats. Not sure about improved safety as ordering misuse/ignorance can often be equally unsafe. Mixing non-atomic ops and atomic ops can sometimes be valid. Would a generic Atomic(T) type with load/storeUnchecked() and limiting fetchXX()/bitXX() for when T is an Int be a good compromise?

[LemonBoy]

atomic int and bool dont contain cmpxchg abstractions

Should be added if needed.

there aren't any such wrappers for atomic pointers/enums/floats

Wrappers for pointers and enums are also a good idea. Floating point types can be added later (if ever) when somebody finds an use for those.

Not sure about improved safety as ordering misuse/ignorance can often be equally unsafe.

The wrappers try to protect the user from shooting themselves in the foot by checking the ordering parameter, avoid defining meaningless operations, and preventing the mix-up of atomic & non atomic ops. The idea of wrapper types is not novel (see Rust or C11) and strikes a good balance between ergonomics and safety.

Would a generic Atomic(T)

I think separate wrapper types are simpler to define, you need quite a bit of meta programming and usingnamespace to achieve the same effect and define some helpers only when they make sense.

[kprotty]

Separate wrapper types feels like repetition: They would all expose load/store/xchg/cmpxchg and ordering checks. Floats would expose that plus arithmetic rmw. Ints would expose even that plus bitwise rmw. Theres few metaprogramming conditions but it covers a lot of cases. Thats my pitch for Atomic(T)

[LemonBoy]

Thats my pitch for Atomic(T)

I'm sold!
Given we're in for some sweeping changes, what do you think of using the same nomenclature as the C++ atomic types (load, store, exchange, fetch{Add,Sub,...}, compareExchange{Strong,Weak},...) ?

[kprotty]

I prefer everything except the exchange bits - replacing them for swap/[try]compareAndSwap is on average shorter and is reminiscent of Go's atomic naming scheme.

Actually, another issue with wrapper types is being able to store them inside extern struct/union. Could store the generic bytes and cast between them like atomic_bytes: [@sizeOf(Atomic(T))] align(@alignOf(Atomic(T)) but that is pretty hacky.

[LemonBoy]

Actually, another issue with wrapper types is being able to store them inside extern struct/union

There should be no problem if the wrapper is extern.

[kprotty]

freebsd CI: atomic.zig:25:13: error: expected 0 parameters, found 1

atomic.zig:25: @fence(ordering)

Whats up with the fence builtin?

[LemonBoy]

Change this line.

[kprotty]

@LemonBoy Any further comments before it gets merged?

[LemonBoy]

LGTM.
The size of type T is actually bounded by the combination of architecture and feature flags being used, an extra check can be added at a later stage though.

[LemonBoy]

Suggested change

	comptime var success_is_stronger = switch (failure) {
	comptime const success_is_stronger = switch (failure) {