Before we consider adding new synchronization APIs, we need a clearly defined use case for why a portable application would need this. ODP implementations may make use of such things based on their knowledge of the platform architecture, but ODP applications (should) have no such platform-specific dependencies. So we need a platform-independent use case.
On Sun, Sep 10, 2017 at 10:28 PM, Brian Brooks <brian.bro...@linaro.org> wrote: > Hi Andriy, > > On Wed, Sep 6, 2017 at 12:24 PM, Andriy Berestovskyy > <andriy.berestovs...@caviumnetworks.com> wrote: >> Hey Brian, >> You are right, there are no compiler barriers on master, I just was on >> api-next branch: >> >> https://git.linaro.org/lng/odp.git/tree/platform/linux-generic/arch/arm/odp_atomic.h?h=api-next#n56 > > How about a #define for compiler barrier in odp_compiler_internal.h? > >> Andriy >> >> >> On 05.09.2017 17:06, Brian Brooks wrote: >>> >>> I don't see a compiler barrier in the odp.git repo. Perhaps 'nop', but >>> this acts as more than a pure compiler barrier? >>> >>> >>> On Tue, Sep 5, 2017 at 8:23 AM, Andriy Berestovskyy >>> <andriy.berestovs...@caviumnetworks.com> wrote: >>>> >>>> Hey Petri, >>>> >>>> On 05.09.2017 14:17, Savolainen, Petri (Nokia - FI/Espoo) wrote: >>>>> >>>>> >>>>> 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. >>>> >>>> >>>> >>>> >>>> No, compiler barrier does not guarantee CPU order. Though, sometimes we >>>> do >>>> not need such a guarantee. >>>> >>>> Compiler barriers are in the same league with volatiles and provide the >>>> same >>>> weak guarantees: eventually the effect will be observed and code will not >>>> be >>>> optimized out by the compiler. >>>> >>>> >>>> >>>>> 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. >>>> >>>> >>>> >>>> >>>> The barrier is quite rare, so it might remain in form of asm volatile... >>>> >>>> >>>> Andriy
