11.4.3 The Flush Operation The memory model has relaxed-consistency because a thread's temporary view of memory is not required to be consistent with memory at all times.A value written to a variable can remain in the thread's temporary view until it is forced to memory at a later time.Likewise,a read from a variable may retrieve the value from the thread's 67 unless it is for ced to read fro ry.The OpenMP fush operation rteney betwcen the temporary view and memory The flush operation is applied to a set of variables called the flush-set.The flush 101 otherwise do.Impler mentatio ns must not r 12 operation that refers to the same variable. 1 If a thread has performed a write to its temporary view of a shared variable since its last 14 flush of that variable,then when it executes another flush of the variable,the flush does 1516 not complete until the value of the in memory If a thread performs multiple writes to the same variable between two flushes of that 17 variable,the flush ensures that the value of the last write is written to the variable in 1 memory.A flush of a variable executed by a thread also causes its temporary view of the 19 variable to be discarded,so that if its next memory operation for that variable is a read. then the thread will read from memory when itn gain capture the value in the 21 temporary view.When a fush,no ater memory operation by that 2 thread for a variable involved in that flush is allowed to start until the flush completes The completion of a flush of a set of variables executed by a thread is defined as the point at which all writes to those variables performed by the thread before the flush are visible in memory to all other threads and that thread's temporary view of all variables involved is discarded 27 The flush operation provides a guarantee of consistency between a thread's temporary view and memory.Therefore,the flush operation can be used to guarantee that a value written to a variable by one thread may be read by a second thread.To accomplish this 31 ogrammer must ensure that the second thread has not written to the variable si the p flush of the variable,and that the following sequence of events happens in the 3 specified order: 33 1.The value is written to the variable by the first thread. 34 2.The variable is flushed by the first thread. 35 3.The variable is flushed by the second thread. 36 4.The value is read from the variable by the second thread Chapter 1 Introduction 19
Chapter 1 Introduction 19 1.4.3 The Flush Operation The memory model has relaxed-consistency because a thread’s temporary view of memory is not required to be consistent with memory at all times. A value written to a variable can remain in the thread’s temporary view until it is forced to memory at a later time. Likewise, a read from a variable may retrieve the value from the thread’s temporary view, unless it is forced to read from memory. The OpenMP flush operation enforces consistency between the temporary view and memory. The flush operation is applied to a set of variables called the flush-set. The flush operation restricts reordering of memory operations that an implementation might otherwise do. Implementations must not reorder the code for a memory operation for a given variable, or the code for a flush operation for the variable, with respect to a flush operation that refers to the same variable. If a thread has performed a write to its temporary view of a shared variable since its last flush of that variable, then when it executes another flush of the variable, the flush does not complete until the value of the variable has been written to the variable in memory. If a thread performs multiple writes to the same variable between two flushes of that variable, the flush ensures that the value of the last write is written to the variable in memory. A flush of a variable executed by a thread also causes its temporary view of the variable to be discarded, so that if its next memory operation for that variable is a read, then the thread will read from memory when it may again capture the value in the temporary view. When a thread executes a flush, no later memory operation by that thread for a variable involved in that flush is allowed to start until the flush completes. The completion of a flush of a set of variables executed by a thread is defined as the point at which all writes to those variables performed by the thread before the flush are visible in memory to all other threads and that thread’s temporary view of all variables involved is discarded. The flush operation provides a guarantee of consistency between a thread’s temporary view and memory. Therefore, the flush operation can be used to guarantee that a value written to a variable by one thread may be read by a second thread. To accomplish this, the programmer must ensure that the second thread has not written to the variable since its last flush of the variable, and that the following sequence of events happens in the specified order: 1. The value is written to the variable by the first thread. 2. The variable is flushed by the first thread. 3. The variable is flushed by the second thread. 4. The value is read from the variable by the second thread. 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 30 31 32 33 34 35 36
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
Implementations are allowed to relax the ordering imposed by implicit flush operations when the result is only visible to programs using non-sequentially consistent atomic directives. 41.5 OpenMP Compliance An implementation of the OpenMP API is compliant if and only if it compiles and 67 executes all conforming programs according to the syntax and semantics laid out in Chapters 1,2.3 and 4.A endices A.B.C.D.E and F and sections designated as Notes 89 specification. 10 The OpenMP API defines constructs that operate in the context of the base language that 11 1213 required to support it,with the exception that for Fortran,the implementation must 14 allow case insensitivity for directive and API routines names,and must allow identifiers 15 of more than six characters. 167 All library,intrinsic and built-in tines provided by the base languag inmmmetation.Inadd.the me 1 language must also be thread-safe.For example,ALLOCATE and DEALLOCATE 19 statements must be thread-safe in Fortran.Unsynchronized concurrent use of such 20 routines by different threads must produce correct results(although not necessarily the 2 same as serial execution results,as in the case of random number generation routines) 22 Starting with Fortran 90,variables with explicit initialization have the SAVE attribute 23 implicitly.This is not the case in Fortran 77.However,a compliant OpenMP Fortran implementation must give such a variable the sAvE attribute,regardless of the 25 underlying base language version. 2 Appendix D lists certain aspects of the OpenMP API that are implementation defined.A compliant implementation is required to define and document its behavior for each of 28 the items in Appendix D. Chapter 1 Introduction 21
Chapter 1 Introduction 21 Implementations are allowed to relax the ordering imposed by implicit flush operations when the result is only visible to programs using non-sequentially consistent atomic directives. 1.5 OpenMP Compliance An implementation of the OpenMP API is compliant if and only if it compiles and executes all conforming programs according to the syntax and semantics laid out in Chapters 1, 2, 3 and 4. Appendices A, B, C, D, E and F and sections designated as Notes (see Section 1.7 on page 23) are for information purposes only and are not part of the specification. The OpenMP API defines constructs that operate in the context of the base language that is supported by an implementation. If the base language does not support a language construct that appears in this document, a compliant OpenMP implementation is not required to support it, with the exception that for Fortran, the implementation must allow case insensitivity for directive and API routines names, and must allow identifiers of more than six characters. All library, intrinsic and built-in routines provided by the base language must be threadsafe in a compliant implementation. In addition, the implementation of the base language must also be thread-safe. For example, ALLOCATE and DEALLOCATE statements must be thread-safe in Fortran. Unsynchronized concurrent use of such routines by different threads must produce correct results (although not necessarily the same as serial execution results, as in the case of random number generation routines). Starting with Fortran 90, variables with explicit initialization have the SAVE attribute implicitly. This is not the case in Fortran 77. However, a compliant OpenMP Fortran implementation must give such a variable the SAVE attribute, regardless of the underlying base language version. Appendix D lists certain aspects of the OpenMP API that are implementation defined. A compliant implementation is required to define and document its behavior for each of the items in Appendix D. 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
11.6 Normative References ISOlEC 9899:1990,Information Technology-Programming Languages-C. This OpenMP API specification refers to ISO/IEC 9899:1990 as C90. 5 6 ISOlEC 9899:1999,Information Technology-Programming Languages-C. This OpenMP API specification refers to ISO/IEC9899:1999 as C99 ISO/IEC 14882:1998,Information Technology-Programming Languages-C++. 10 This OpenMP API specification refers to ISO/IEC 14882:1998 as C++ ISO/EC 1539:1980,Information Technology-Programming Languages-Fortran. 13 This OpenMP API specification refers to ISO/IEC 1539:1980 as Fortran 77. 14 ISOMEC 1539:1991,Information Technology-Programming Languages-Fortran. This OpenMP API specification refers to ISO/IEC 1539:1991 as Fortran 90. 17 18 ISONEC 1539-1:1997,Information Technology-Programming Languages-Fortran 19 This OpenMP API specification refers to ISO/IEC 1539-1:1997 as Fortran 95. 20 21 ISOMEC 1539-1:2004,Information Technology-Programming Languages-Fortran 22 This OpenMP API specification refers to ISO/IEC 1539-1:2004 as Fortran 2003.The following features are not supported: 24 IEEE Arithmetic issues covered in Fortran 2003 Section 14 Allocatable enhancement 2 Parameterized derived types ·Finalization 28 Procedures bound by name to a type 9 ·The PASS attribute 22 OpenMP API.Version 4.0-July 2013
22 OpenMP API • Version 4.0 - July 2013 1.6 Normative References • ISO/IEC 9899:1990, Information Technology - Programming Languages - C. This OpenMP API specification refers to ISO/IEC 9899:1990 as C90. • ISO/IEC 9899:1999, Information Technology - Programming Languages - C. This OpenMP API specification refers to ISO/IEC 9899:1999 as C99. • ISO/IEC 14882:1998, Information Technology - Programming Languages - C++. This OpenMP API specification refers to ISO/IEC 14882:1998 as C++. • ISO/IEC 1539:1980, Information Technology - Programming Languages - Fortran. This OpenMP API specification refers to ISO/IEC 1539:1980 as Fortran 77. • ISO/IEC 1539:1991, Information Technology - Programming Languages - Fortran. This OpenMP API specification refers to ISO/IEC 1539:1991 as Fortran 90. • ISO/IEC 1539-1:1997, Information Technology - Programming Languages - Fortran. This OpenMP API specification refers to ISO/IEC 1539-1:1997 as Fortran 95. • ISO/IEC 1539-1:2004, Information Technology - Programming Languages - Fortran. This OpenMP API specification refers to ISO/IEC 1539-1:2004 as Fortran 2003. The following features are not supported: • IEEE Arithmetic issues covered in Fortran 2003 Section 14 • Allocatable enhancement • Parameterized derived types • Finalization • Procedures bound by name to a type • The PASS attribute 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
Procedures bound to a type as operators ·Type extension Overriding a type-bound procedure Polymorphic entities 5 SELECT TYPE construct 6 Deferred bindings and abstract types > Controlling IEEE underflow 8 Another IEEE class value Where this OpenMP API specification refers to C,C++or Fortran,reference is made to 10 the base language supported by the implementation. 111.7 Organization of this document 12 The remainder of this document is structured as follows 13 Chapter 2"Directives" 14 ·Chapter3“Runtime Library Routines' 15 ·Chapter4“Environment Variables" 16 ·Appendix A“Stubs for Runtime Library Routines"” 17 ·Appendix B“OpenMP C and C+Grammar' ·Appendix C"Interface Declarations” 19 Appendix D"OpenMP Implementation-Defined Behaviors" ·Appendix E“Features History" 2 Some secions of this document ony apply to programs written inaerain base language.Text that applies only to programs whose base language is Cor C++is shown as follows: C/C++ 24 C/C++specific text.. C/C++ A 25 Text that applies only to programs whose base language is C only is shown as follows: 26 C specific text. Chapter 1 Introduction 23
Chapter 1 Introduction 23 • Procedures bound to a type as operators • Type extension • Overriding a type-bound procedure • Polymorphic entities • SELECT TYPE construct • Deferred bindings and abstract types • Controlling IEEE underflow • Another IEEE class value Where this OpenMP API specification refers to C, C++ or Fortran, reference is made to the base language supported by the implementation. 1.7 Organization of this document The remainder of this document is structured as follows: • Chapter 2 “Directives” • Chapter 3 “Runtime Library Routines” • Chapter 4 “Environment Variables” • Appendix A “Stubs for Runtime Library Routines” • Appendix B “OpenMP C and C++ Grammar” • Appendix C “Interface Declarations” • Appendix D “OpenMP Implementation-Defined Behaviors” • Appendix E “Features History” Some sections of this document only apply to programs written in a certain base language. Text that applies only to programs whose base language is C or C++ is shown as follows: C/C++ C/C++ C/C++ specific text... Text that applies only to programs whose base language is C only is shown as follows: C C C specific text... 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