SummaryThe critical construct restricts execution of the associated structured block to a single thread at a time.
Syntax
The syntax of the critical construct is as follows:
!$omp critical [(name) [[,] hint(hint-expression)] ]
structured-block
!$omp end critical [(name)]
where hint-expression is a constant expression that evaluates to a scalar value with kind omp_sync_hint_kind and a value that is a valid synchronization hint (as described in Section 2.17.12 on page 746).
BindingThe binding thread set for a critical region is all threads in the contention group.
DescriptionThe region that corresponds to a critical construct is executed as if only a single thread at a time among all threads in the contention group enters the region for execution, without regard to the team(s) to which the threads belong. An optional name may be used to identify the critical construct. All critical constructs without a name are considered to have the same unspecified name.
Identifiers 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 identifiers.
The names of critical constructs are global entities of the program. If a name conflicts with any other entity, the behavior of the program is unspecified.
The threads of a contention group execute the critical region as if only one thread of the contention group executes the critical region at a time. The critical construct enforces these execution semantics with respect to all critical constructs with the same name in all threads in the contention group.
If present, the hint clause gives the implementation additional information about the expected runtime properties of the critical region that can optionally be used to optimize the implementation. The presence of a hint clause does not affect the isolation guarantees provided by the critical construct. If no hint clause is specified, the effect is as if hint(omp_sync_hint_none) had been specified.
Execution Model EventsThe 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 CallbacksA 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 specific kind is acceptable.
RestrictionsThe following restrictions apply to the critical construct: