11.4 Memory Model 21.4.1 Structure of the OpenMP Memory Model 3 The OpenMP API provides a relaxed-consistency,shared-memory model.All OpenMP threads have access to a place to store and to retrieve variables,called the memory.In 6 addition,each thread is allowed to have its own temporary view of the memory.The 67 rtheadsotud pa of the enM kind as machine registers,cache,or other local storage,between the thread and the memory.The temporary view of memory allows the thread to cache variables and thereby to avoid 10 going to memory for every reference to a variable.Each thread also has access to 11 another type of memory that must not be accessed by other threads,called threadprivate 12 memory. 13 A directive that accepts data-sharing attribute clauses determines two kinds of access to 14 variables used in the directive's associated structured block:shared and private.Each 15 variable referenced in the structured block has an original variable,which is the variable 16718 by the same namee te roam immedately outside the construct Fach refer ence to a sha ucture red block becomesa refer rence to the original variable.For each private variable referenced in the structured block,a new version of 9 the original variable (of the same type and size)is created in memory for each task or SIMD lane that contains code associated with the directive.Creation of the new version 21 does not alter the value of the original variable.However,the impact of attempts to access the original variable during the region associated with the directive is 23 unspecified: details Referencestoa private variable in the structured block refer to the private version of the original variable for the current task or SIMD lane.The relationship between the value of the original variable and the initial or final value of the private version depends on the exact 27 clause that specifies it.Details of this issue,as well as other issues with privatization. are provided in Section 2.14 on page 146. 29 The minimum size at which a memory update may also read and write back adjacent variables that are part of another variable (as array or structure elements)is 31 implementation defined but is no larger than required by the base language. 3 A single access to a variable may be implemented with multiple load or store instructions,and hence is not guaranteed to be atomic with respect to other accesses to 34 the same variable.Accesses to variables smaller than the implementation defined 35 minimum size or to C or C++bit-fields may be implemented by reading,modifying,and rewriting a larger unit of memory,and may thus interfere with updates of variables or 37 fields in the same unit of memory. Chapter 1 Introduction 17Chapter 1 Introduction 17 1.4 Memory Model 1.4.1 Structure of the OpenMP Memory Model The OpenMP API provides a relaxed-consistency, shared-memory model. All OpenMP threads have access to a place to store and to retrieve variables, called the memory. In addition, each thread is allowed to have its own temporary view of the memory. The temporary view of memory for each thread is not a required part of the OpenMP memory model, but can represent any kind of intervening structure, such as machine registers, cache, or other local storage, between the thread and the memory. The temporary view of memory allows the thread to cache variables and thereby to avoid going to memory for every reference to a variable. Each thread also has access to another type of memory that must not be accessed by other threads, called threadprivate memory. A directive that accepts data-sharing attribute clauses determines two kinds of access to variables used in the directive’s associated structured block: shared and private. Each variable referenced in the structured block has an original variable, which is the variable by the same name that exists in the program immediately outside the construct. Each reference to a shared variable in the structured block becomes a reference to the original variable. For each private variable referenced in the structured block, a new version of the original variable (of the same type and size) is created in memory for each task or SIMD lane that contains code associated with the directive. Creation of the new version does not alter the value of the original variable. However, the impact of attempts to access the original variable during the region associated with the directive is unspecified; see Section 2.14.3.3 on page 159 for additional details. References to a private variable in the structured block refer to the private version of the original variable for the current task or SIMD lane. The relationship between the value of the original variable and the initial or final value of the private version depends on the exact clause that specifies it. Details of this issue, as well as other issues with privatization, are provided in Section 2.14 on page 146. The minimum size at which a memory update may also read and write back adjacent variables that are part of another variable (as array or structure elements) is implementation defined but is no larger than required by the base language. A single access to a variable may be implemented with multiple load or store instructions, and hence is not guaranteed to be atomic with respect to other accesses to the same variable. Accesses to variables smaller than the implementation defined minimum size or to C or C++ bit-fields may be implemented by reading, modifying, and rewriting a larger unit of memory, and may thus interfere with updates of variables or fields in the same unit of memory. 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 37