On Sun, Sep 10, 2017 at 10:33 PM, Bill Fischofer <bill.fischo...@linaro.org> wrote: > 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.
There's a disconnect here. odp_compiler_internal.h implies platform/xxx/include/odp_compiler_internal.h. That would be the location to add a compiler barrier macro for implementation use only. I think there's enough consensus in this thread to say that there's no need to add an ODP API for a compiler barrier. This same rationale could be extended to all shared memory synchronization algorithms (deprecate them from ODP API) since they are not Control / Data Plane objects and are implemented using atomic primitives (which are an abstraction layer provided by the compiler). Perhaps they should be moved to a odp-helper-sync library that depends on an odp-helper-atomic library. > 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
