define LFDS700_PAL_BARRIER_COMPILER_FULL

From liblfds.org
Revision as of 05:47, 14 December 2015 by Admin (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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.

See Also