Revision as of 18:11, 16 February 2017 by Admin (talk | contribs) (1 revision imported)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Source File



#define LFDS711_PAL_BARRIER_PROCESSOR_LOAD  [processor load barrier directive]


#define LFDS711_PAL_BARRIER_PROCESSOR_LOAD  __atomic_thread_fence( __ATOMIC_ACQ )


This define is not mandatory, the library will compile without it, but if it is actually needed, and not provided, then things can go wrong (they might not, but it would be purely by chance). If it not provided, it must be absent, rather than being empty.


Processors 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 processor 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 processor 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 processor load barrier, where a processor load barrier the prevents the processor re-ordering load operations below the barrier above the barrier and prevents the processor re-ordering load operations above the barrier to below the barrier.

See Also