critical Construct

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

15.2 critical Construct


Name: critical	Association: block
Category: executable	Properties: thread-limiting

Arguments

critical(name)


Name	Type	Properties

name	base language identiﬁer	optional

Clauses

hint

Binding

The binding thread set for a critical region is all threads in the contention group.

Semantics

The name argument is used to identify the critical construct. For any critical construct for which name is not speciﬁed, the eﬀect is as if an identical (unspeciﬁed) name was speciﬁed. The region that corresponds to a critical construct of a given name is executed as if only a single thread at a time among all threads in the contention group executes the region, without regard to the teams to which the threads belong.

Identiﬁers used to identify a critical construct have external linkage and are in a name space that is separate from the name spaces used by labels, tags, members, and ordinary identiﬁers.

The names of critical constructs are global entities of the program. If a name conﬂicts with any other entity, the behavior of the program is unspeciﬁed.

Execution Model Events

The critical-acquiring event occurs in a thread that encounters the critical construct on entry to the critical region before initiating synchronization for the region.

The critical-acquired event occurs in a thread that encounters the critical construct after it enters the region, but before it executes the structured block of the critical region.

The critical-released event occurs in a thread that encounters the critical construct after it completes any synchronization on exit from the critical region.

Tool Callbacks

A thread dispatches a registered ompt_callback_mutex_acquire callback for each occurrence of a critical-acquiring event in that thread. This callback has the type signature ompt_callback_mutex_acquire_t.

A thread dispatches a registered ompt_callback_mutex_acquired callback for each occurrence of a critical-acquired event in that thread. This callback has the type signature ompt_callback_mutex_t.

A thread dispatches a registered ompt_callback_mutex_released callback for each occurrence of a critical-released event in that thread. This callback has the type signature ompt_callback_mutex_t.

The callbacks occur in the task that encounters the critical construct. The callbacks should receive ompt_mutex_critical as their kind argument if practical, but a less speciﬁc kind is acceptable.

Restrictions

Restrictions to the critical construct are as follows:

Unless omp_sync_hint_none is speciﬁed, the critical construct must specify a name.
The hint-expr that is applied to each of the critical constructs with the same name must evaluate to the same value.

∙ If a name is speciﬁed on a critical directive, the same name must also be speciﬁed on the end critical directive. ∙ If no name appears on the critical directive, no name can appear on the end critical directive.

Cross References

ompt_callback_mutex_acquire_t, see Section 19.5.2.14
ompt_callback_mutex_t, see Section 19.5.2.15
ompt_mutex_t, see Section 19.4.4.17
hint clause, see Section 15.1.2

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