CODEWITHSUNDEEP
linux-kernelarmarm64atomicmemory-barriers
scopichmu
scopichmu

Reputation: 145

why does arm atomic_[read/write] operations implemented as volatile pointers?

He is example of atomic_read implementation:

#define atomic_read(v) (*(volatile int *)&(v)->counter)

Also, should we explicitly use memory barriers for atomic operations on arm?

Upvotes: 1

Views: 828

Answers (2)

curiousguy
curiousguy

Reputation: 8270

He is example of atomic_read implementation:

A problematic one actually, which assumes that a cast is not a nop, which isn't guaranteed.

Also, should we explicitly use memory barriers for atomic operations on arm?

Probably. It depends on what you are doing and what you are expecting.

Upvotes: 1

Geoffrey Blake
Geoffrey Blake

Reputation: 179

Yes, the casting to volatile is to prevent the compiler from assuming the value of v cannot change. As for using memory barriers, the GCC builtins already allow you to specify the memory ordering you desire, no need to do it manually: https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/_005f_005fatomic-Builtins.html#g_t_005f_005fatomic-Builtins

The default behavior on GCC is to use __ATOMIC_SEQ_CST which will emit the barriers necessary on Arm to make sure your atomics execute in the order you place them in the code. To optimize performance on Arm, you will want to consider using weaker semantics to allow the compiler to elide barriers and let the hardware execute faster. For more information on the types of memory barriers the Arm architecture has, see https://developer.arm.com/docs/den0024/latest/memory-ordering/barriers.

Upvotes: 1

Related Questions