> -----Original Message----- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of > Andriy Berestovskyy > Sent: Tuesday, September 05, 2017 2:08 PM > To: lng-odp@lists.linaro.org > Subject: Re: [lng-odp] Compiler Barrier API > > Hey Maxim, > There is a use case in the ODP code itself just search for the > volatile("" ::: "memory"). It is rare, just like all the barriers. > > We also have compiler barrier in our code, so I just thought it would be > nice to add this to the api/sync.h, i.e.: > > /** > * Compiler barrier > * > * This is a compiler barrier. It prevents compiler to rearrange > * access operations before the barrier with operations after it. > * > * It also forces compiler to load variables used in loop condition > * each loop cycle. > * > * This call is not needed when using ODP defined synchronization > * mechanisms. > */ > void odp_compiler_barrier(void); > > > With the following definition: > > static inline void odp_compiler_barrier(void) > { > __asm__ volatile("": : :"memory"); > } > > It it is OK with you, I can prepare a proper patch. > > Andriy >
I think compiler barrier is too weak for writing portable code, since it does not guarantee that the CPU would not re-order the instructions. Application should use ODP memory barriers (odp_mb_full(), odp_mb_acquire(), etc) or atomics with memory ordering (odp_atomic_load_acq_u64(), odp_atomic_store_rel_u64()). ODP implementation has ":::memory" in context of inline assembly instructions, but that's when we are writing code against specific ISA and thus know which amount of synchronization is needed. A portable application cannot assume any particular ISA. -Petri
