define LFDS700_PAL_BARRIER_COMPILER_FULL
Source File
└───liblfds700
└───inc
└───liblfds700
lfds700_lfds700_porting_abstraction_layer_compiler.h
Define
#define LFDS700_PAL_BARRIER_COMPILER_FULL [compiler full compiler barrier directive]
Example
#define LFDS700_PAL_BARRIER_COMPILER_FULL _ReadWriteBarrier()
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 full barrier, where a compiler full barrier the prevents the compiler re-ordering both loads and store operations below the barrier to be above the barrier and prevents the compiler re-ordering both loads and store operations above the barrier to below the barrier.