12 4,are recommended for enforcing this order.Synchronization through variables is possible but is not recommended because the proper timing of g flushes is difficult. 51.4.4 OpenMP Memory Consistency 67 The restrictions in Section 1.4.3 on page 19 on reordering with respect to flush operations guarantee the following: 8 If the intersection of the flush-sets of two flushes performed by two different threads is non-empty,then the two flushes must be completed as if in some sequential order, O seen by all threads. If two operations performed by the same thread either access,modify,or flush the 12 same variable,then they must be completed as if in that thread's program order,as 13 seen by all threads. 14 If the intersection of the flush-sets of two flushes is empty,the threads can observe these flushes in any order. The flush operation can be specified using the flush directive,and is also implied at 17 various locations in an OpenMP program:see Section 2.12.7 on page 134 for details. by themselves prevent data operations are only useful in combination with non-sequentially consistent atomic 20 directives. 21 OpenMP programs that: 22 do not use non-sequentially consistent atomic directives, 效 do not rely on the accuracy of a false result from omp_testlock and omp test nest lock.and 25 correctly avoid data races as required in Section 1.4.1 on page 17 behave as though operations on shared variables were simply interleaved in an order 27 consistent with theorder in which they are performed by each thread.The relaxed 2829 consistency model is invisible for such programs,and any explicit flush operations in such programs are redundant 20 OpenMP API.Version 4.0-July 2013 20 OpenMP API • Version 4.0 - July 2013 Note – OpenMP synchronization operations, described in Section 2.12 on page 120 and in Section 3.3 on page 224, are recommended for enforcing this order. Synchronization through variables is possible but is not recommended because the proper timing of flushes is difficult. 1.4.4 OpenMP Memory Consistency The restrictions in Section 1.4.3 on page 19 on reordering with respect to flush operations guarantee the following: • If the intersection of the flush-sets of two flushes performed by two different threads is non-empty, then the two flushes must be completed as if in some sequential order, seen by all threads. • If two operations performed by the same thread either access, modify, or flush the same variable, then they must be completed as if in that thread's program order, as seen by all threads. • If the intersection of the flush-sets of two flushes is empty, the threads can observe these flushes in any order. The flush operation can be specified using the flush directive, and is also implied at various locations in an OpenMP program: see Section 2.12.7 on page 134 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 on page 17 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. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29