threadprivate Directive

| OPENMP API Specification: "Version 5.2 -- GIT rev 95b2e3a44"

5.2 threadprivate Directive


Name: threadprivate	Association: none
Category: declarative	Properties: default

Arguments

threadprivate(list)


Name	Type	Properties

list	list of variable list item type	default

Semantics

The threadprivate directive speciﬁes that variables are replicated, with each thread having its own copy. Unless otherwise speciﬁed, each copy of a threadprivate variable is initialized once, in the manner speciﬁed by the program, but at an unspeciﬁed point in the program prior to the ﬁrst reference to that copy. The storage of all copies of a threadprivate variable is freed according to how static variables are handled in the base language, but at an unspeciﬁed point in the program.

Each copy of a block-scope threadprivate variable that has a dynamic initializer is initialized the ﬁrst time its thread encounters its deﬁnition; if its thread does not encounter its deﬁnition, its initialization is unspeciﬁed.

The content of a threadprivate variable can change across a task scheduling point if the executing thread switches to another task that modiﬁes the variable. For more details on task scheduling, see Section 1.3 and Chapter 12.

In parallel regions, references by the primary thread are to the copy of the variable in the thread that encountered the parallel region.

During a sequential part, references are to the initial thread’s copy of the variable. The values of data in the initial thread’s copy of a threadprivate variable are guaranteed to persist between any two consecutive references to the variable in the program, provided that no teams construct that is not nested inside of a target construct is encountered between the references and that the initial thread is not executing code inside of a teams region. For initial threads that are executing code inside of a teams region, the values of data in the copies of a threadprivate variable of those initial threads are guaranteed to persist between any two consecutive references to the variable inside that teams region.

The values of data in the threadprivate variables of threads that are not initial threads are guaranteed to persist between two consecutive active parallel regions only if all of the following conditions hold:

Neither parallel region is nested inside another explicit parallel region;
The sizes of the thread teams used to execute both parallel regions are the same;
The thread aﬃnity policies used to execute both parallel regions are the same;
The value of the dyn-var internal control variable in the enclosing task region is false at entry to both parallel regions;
No teams construct that is not nested inside of a target construct is encountered between the parallel regions;
No construct with an order clause that speciﬁes concurrent is encountered between the parallel regions; and
Neither the omp_pause_resource nor omp_pause_resource_all routine is called.

If these conditions all hold, and if a threadprivate variable is referenced in both regions, then threads with the same thread number in their respective regions reference the same copy of that variable.

If the above conditions hold, the storage duration, lifetime, and value of a thread’s copy of a threadprivate variable that does not appear in any copyin clause on the corresponding construct of the second region spans the two consecutive active parallel regions. Otherwise, the storage duration, lifetime, and value of a thread’s copy of the variable in the second region is unspeciﬁed.

If the above conditions hold, the deﬁnition, association, or allocation status of a thread’s copy of a threadprivate variable or a variable in a threadprivate common block that is not aﬀected by any copyin clause that appears on the corresponding construct of the second region (a variable is aﬀected by a copyin clause if the variable appears in the copyin clause or it is in a common block that appears in the copyin clause) spans the two consecutive active parallel regions. Otherwise, the deﬁnition and association status of a thread’s copy of the variable in the second region are undeﬁned, and the allocation status of an allocatable variable are implementation deﬁned.

If a threadprivate variable or a variable in a threadprivate common block is not aﬀected by any copyin clause that appears on the corresponding construct of the ﬁrst parallel region in which it is referenced, the thread’s copy of the variable inherits the declared type parameter and the default parameter values from the original variable. The variable or any subobject of the variable is initially deﬁned or undeﬁned according to the following rules:

If it has the ALLOCATABLE attribute, each copy created has an initial allocation status of unallocated;
If it has the POINTER attribute, each copy has the same association status as the initial association status.
If it does not have either the POINTER or the ALLOCATABLE attribute:
- If it is initially deﬁned, either through explicit initialization or default initialization, each copy created is so deﬁned;
- Otherwise, each copy created is undeﬁned.

The order in which any constructors for diﬀerent threadprivate variables of class type are called is unspeciﬁed. The order in which any destructors for diﬀerent threadprivate variables of class type are called is unspeciﬁed.

Restrictions

Restrictions to the threadprivate directive are as follows:

A thread must not reference another thread’s copy of a threadprivate variable.
A threadprivate variable must not appear as the base variable of a list item in any clause except for the copyin and copyprivate clauses.
A program in which an untied task accesses threadprivate storage is non-conforming.

∙ Each list item must be a ﬁle-scope, namespace-scope, or static block-scope variable. ∙ No list item may have an incomplete type. ∙ The address of a threadprivate variable must not be an address constant. ∙ If the value of a variable referenced in an explicit initializer of a threadprivate variable is modiﬁed prior to the ﬁrst reference to any instance of the threadprivate variable, the behavior is unspeciﬁed. ∙ A variable that is part of another variable (as an array element or a structure element) cannot appear in a threadprivate directive unless it is a static data member of a C++ class. ∙ A threadprivate directive for ﬁle-scope variables must appear outside any deﬁnition or declaration, and must lexically precede all references to any of the variables in its list. ∙ A threadprivate directive for namespace-scope variables must appear outside any deﬁnition or declaration other than the namespace deﬁnition itself and must lexically precede all references to any of the variables in its list. ∙ Each variable in the list of a threadprivate directive at ﬁle, namespace, or class scope must refer to a variable declaration at ﬁle, namespace, or class scope that lexically precedes the directive. ∙ A threadprivate directive for static block-scope variables must appear in the scope of the variable and not in a nested scope. The directive must lexically precede all references to any of the variables in its list. ∙ Each variable in the list of a threadprivate directive in block scope must refer to a variable declaration in the same scope that lexically precedes the directive. The variable must have static storage duration. ∙ If a variable is speciﬁed in a threadprivate directive in one translation unit, it must be speciﬁed in a threadprivate directive in every translation unit in which it is declared.
∙ A threadprivate directive for static class member variables must appear in the class deﬁnition, in the same scope in which the member variables are declared, and must lexically precede all references to any of the variables in its list. ∙ A threadprivate variable must not have an incomplete type or a reference type. ∙ A threadprivate variable with class type must have:
- An accessible, unambiguous default constructor in the case of default initialization without a given initializer;
- An accessible, unambiguous constructor that accepts the given argument in the case of direct initialization; and
- An accessible, unambiguous copy constructor in the case of copy initialization with an explicit initializer.

Each list item must be a named variable or a named common block; a named common block must appear between slashes.
The list argument must not include any corrays associate names.
The threadprivate directive must appear in the declaration section of a scoping unit in which the common block or variable is declared.
If a threadprivate directive that speciﬁes a common block name appears in one program unit, then such a directive must also appear in every other program unit that contains a COMMON statement that speciﬁes the same name. It must appear after the last such COMMON statement in the program unit.
If a threadprivate variable or a threadprivate common block is declared with the BIND attribute, the corresponding C entities must also be speciﬁed in a threadprivate directive in the C program.
A variable may only appear as an argument in a threadprivate directive in the scope in which it is declared. It must not be an element of a common block or appear in an EQUIVALENCE statement.
A variable that appears as an argument in a threadprivate directive must be declared in the scope of a module or have the SAVE attribute, either explicitly or implicitly.
The eﬀect of an access to a threadprivate variable in a DO CONCURRENT construct is unspeciﬁed.

Cross References

Determining the Number of Threads for a parallel Region, see Section 10.1.1
copyin clause, see Section 5.7.1
dyn-var ICV, see Section 2.1
order clause, see Section 10.3

[next] [prev] [prev-tail] [front] [up]