mirror of
https://github.com/OpenMP/Examples.git
synced 2025-04-10 16:32:11 +01:00
70 lines
4.1 KiB
TeX
70 lines
4.1 KiB
TeX
\pagebreak
|
|
\chapter{Synchronization}
|
|
\label{chap:synchronization}
|
|
|
|
The \code{barrier} construct is a stand-alone directive that requires all threads
|
|
of a team (within a contention group) to execute the barrier and complete
|
|
execution of all tasks within the region, before continuing past the barrier.
|
|
|
|
The \code{critical} construct is a directive that contains a structured block.
|
|
The construct allows only a single thread at a time to execute the structured block (region).
|
|
Multiple critical regions may exist in a parallel region, and may
|
|
act cooperatively (only one thread at a time in all \code{critical} regions),
|
|
or separately (only one thread at a time in each \code{critical} regions when
|
|
a unique name is supplied on each \code{critical} construct).
|
|
An optional (lock) \code{hint} clause may be specified on a named \code{critical}
|
|
construct to provide the OpenMP runtime guidance in selection a locking
|
|
mechanism.
|
|
|
|
On a finer scale the \code{atomic} construct allows only a single thread at
|
|
a time to have atomic access to a storage location involving a single read,
|
|
write, update or capture statement, and a limited number of combinations
|
|
when specifying the \code{capture} \plc{atomic-clause} clause. The \plc{atomic-clause} clause
|
|
is required for some expression statements, but are not required for
|
|
\code{update} statements. Please see the details in the \plc{atomic Construct}
|
|
subsection of the \plc{Directives} chapter in the OpenMP Specifications document.
|
|
|
|
% The following three sentences were stolen from the spec.
|
|
The \code{ordered} construct either specifies a structured block in a loop,
|
|
simd, or loop SIMD region that will be executed in the order of the loop
|
|
iterations. The ordered construct sequentializes and orders the execution
|
|
of ordered regions while allowing code outside the region to run in parallel.
|
|
|
|
Since OpenMP 4.5 the \code{ordered} construct can also be a stand-alone
|
|
directive that specifies cross-iteration dependences in a doacross loop nest.
|
|
The \code{depend} clause uses a \code{sink} \plc{dependence-type}, along with a
|
|
iteration vector argument (vec) to indicate the iteration that satisfies the
|
|
dependence. The \code{depend} clause with a \code{source}
|
|
\plc{dependence-type} specifies dependence satisfaction.
|
|
|
|
The \code{flush} directive is a stand-alone construct that forces a thread's
|
|
temporal local storage (view) of a variable to memory where a consistent view
|
|
of the variable storage can be accesses. When the construct is used without
|
|
a variable list, all the locally thread-visible data as defined by the
|
|
base language are flushed. A construct with a list applies the flush
|
|
operation only to the items in the list. The \code{flush} construct also
|
|
effectively insures that no memory (load or store) operation for
|
|
the variable set (list items, or default set) may be reordered across
|
|
the \code{flush} directive.
|
|
|
|
General-purpose routines provide mutual exclusion semantics through locks,
|
|
represented by lock variables.
|
|
The semantics allows a task to \plc{set}, and hence
|
|
\plc{own} a lock, until it is \plc{unset} by the task that set it. A
|
|
\plc{nestable} lock can be set multiple times by a task, and is used
|
|
when in code requires nested control of locks. A \plc{simple lock} can
|
|
only be set once by the owning task. There are specific calls for the two
|
|
types of locks, and the variable of a specific lock type cannot be used by the
|
|
other lock type.
|
|
|
|
Any explicit task will observe the synchronization prescribed in a
|
|
\code{barrier} construct and an implied barrier. Also, additional synchronizations
|
|
are available for tasks. All children of a task will wait at a \code{taskwait} (for
|
|
their siblings to complete). A \code{taskgroup} construct creates a region in which the
|
|
current task is suspended at the end of the region until all sibling tasks,
|
|
and their descendants, have completed.
|
|
Scheduling constraints on task execution can be prescribed by the \code{depend}
|
|
clause to enforce dependence on previously generated tasks.
|
|
More details on controlling task executions can be found in the \plc{Tasking} Chapter
|
|
in the OpenMP Specifications document. %(DO REF. RIGHT.)
|