But given that it’s the value that’s volatile and not the address-of, the address-of is fixed per instance, we don’t touch the volatile part in our code.

The implementation of `OSAtomicCompareAndSwap32Barrier` will behave identically whether it’s qualified as volatile or not, because it can’t know that it wasn’t qualified as volatile in our scope. What can change are the rules regarding reads and writes to the variable in our scope, and whether reads/writes can be optimised out, but we don’t make any reads or writes, we just take the address-of.

> The compiler is free to do a lot of optimization without the qualifier

It can’t optimise out the address-of or the function invocation though.

That said we can’t control how the interface `OSAtomicCompareAndSwap32Barrier` is implemented, and it could be changed to be something that doesn’t cross scopes in the future, such as a macro or inline function. From a forward compatible perspective I think it is worth adding the qualifier.