define LFDS700_PAL_BARRIER_COMPILER_LOAD
Source File
└───liblfds700
└───inc
└───liblfds700
lfds700_lfds700_porting_abstraction_layer_compiler.h
Define
#define LFDS700_PAL_BARRIER_COMPILER_LOAD [compiler load barrier directive]
Example
#define LFDS700_PAL_BARRIER_COMPILER_LOAD _ReadBarrier()
Optionality
This define is mandatory, but there is one case where it can be omitted, and if it omitted, the define must be absent, rather than empty, and LFDS700_PAL_NO_COMPILER_BARRIERS must be defined, like so;
// TRD : GCC >= 4.7.3 compiler barriers are built into the processor barrier intrinsics #define LFDS700_PAL_NO_COMPILER_BARRIERS
The one case where this define can be omitted is when a platform always emits a compiler barrier when it emits a processor barrier. One such platform is GCC version 4.7.3 or later.
Notes
Compilers typically are able to re-order the flow of instructions, where this re-ordering is only guaranteed to be valid within the context of a single thread; e.g. if thread A performs an operation and then raises a flag, where thread B is waiting on the flag, the compiler will in its re-ordering only take into account that the behaviour of the thread being re-ordered remains valid, such that in this case we might see in thread A the flag being raised before the operation is performed, since the compiler isn't taking into account that thread B is written on the assumption the flag will be raised after the operation.
Compilers typically offer a directive which acts as a compiler load barrier, where a compiler load barrier the prevents the compiler re-ordering load operations below the barrier to be above the barrier and prevents the compiler re-ordering load operations above the barrier to below the barrier.