1.4.6  OpenMP Memory Consistency

The following rules guarantee an observable completion order for a given pair of memory operations in race-free programs, as seen by all affected threads. If both memory operations are strong flushes, the affected threads are all threads on devices in both of their respective device-sets. If exactly one of the memory operations is a strong flush, the affected threads are all threads on devices in its device-set. Otherwise, the affected threads are all threads.

• If two operations performed by different threads are sequentially consistent atomic operations or they are strong flushes that flush the same variable, then they must be completed as if in some sequential order, seen by all affected threads.
• If two operations performed by the same thread are sequentially consistent atomic operations or they access, modify, or, with a strong flush, flush the same variable, then they must be completed as if in that thread’s program order, as seen by all affected threads.
• If two operations are performed by different threads and one happens before the other, then they must be completed as if in that happens before order, as seen by all affected threads, if:
  • both operations access or modify the same variable;
  • both operations are strong flushes that flush the same variable; or
  • both operations are sequentially consistent atomic operations.
• Any two atomic memory operations from different atomic regions must be completed as if in the same order as the strong flushes implied in their respective regions, as seen by all affected threads.

The flush operation can be specified using the flush directive, and is also implied at various locations in an OpenMP program: see Section 2.19.8 for details.

Note – Since flush operations by themselves cannot prevent data races, explicit flush operations are only useful in combination with non-sequentially consistent atomic directives.

OpenMP programs that:

• Do not use non-sequentially consistent atomic directives;
• Do not rely on the accuracy of a false result from omp_test_lock and omp_test_nest_lock; and
• Correctly avoid data races as required in Section 1.4.1,

behave as though operations on shared variables were simply interleaved in an order consistent with the order in which they are performed by each thread. The relaxed consistency model is invisible for such programs, and any explicit flush operations in such programs are redundant.