HOME
| OPENMP API Specification: Version 5.0 November 2018

2.17.9  ordered Construct

SummaryThe ordered construct either specifies a structured block in a worksharing-loop, simd, or worksharing-loop SIMD region that will be executed in the order of the loop iterations, or it is a stand-alone directive that specifies cross-iteration dependences in a doacross loop nest. The ordered construct sequentializes and orders the execution of ordered regions while allowing code outside the region to run in parallel.

Syntax

SVG-Viewer needed.

The syntax of the ordered construct is as follows:  

 
#pragma omp ordered [clause[ [,] clause] ] new-line 
   structured-block  

where clause is one of the following:  

 
threads 
simd  

or  

 
#pragma omp ordered clause [[[,] clause] ... ] new-line  

where clause is one of the following:  

 
depend(source) 
depend(sink : vec)  

SVG-Viewer needed.

SVG-Viewer needed.

The syntax of the ordered construct is as follows:  

 
!$omp ordered [clause[ [,] clause] ] 
    structured-block 
!$omp end ordered  

where clause is one of the following:  

 
threads 
simd  

or  

 
!$omp ordered clause [[[,] clause] ... ]  

where clause is one of the following:  

 
depend(source) 
depend(sink : vec)  

SVG-Viewer needed.

If the depend clause is specified, the ordered construct is a stand-alone directive.

BindingThe binding thread set for an ordered region is the current team. An ordered region binds to the innermost enclosing simd or worksharing-loop SIMD region if the simd clause is present, and otherwise it binds to the innermost enclosing worksharing-loop region. ordered regions that bind to different regions execute independently of each other.

DescriptionIf no clause is specified, the ordered construct behaves as if the threads clause had been specified. If the threads clause is specified, the threads in the team that is executing the worksharing-loop region execute ordered regions sequentially in the order of the loop iterations. If any depend clauses are specified then those clauses specify the order in which the threads in the team execute ordered regions. If the simd clause is specified, the ordered regions encountered by any thread will execute one at a time in the order of the loop iterations. When the thread that is executing the first iteration of the loop encounters an ordered construct, it can enter the ordered region without waiting. When a thread that is executing any subsequent iteration encounters an ordered construct without a depend clause, it waits at the beginning of the ordered region until execution of all ordered regions belonging to all previous iterations has completed. When a thread that is executing any subsequent iteration encounters an ordered construct with one or more depend(sink:vec) clauses, it waits until its dependences on all valid iterations specified by the depend clauses are satisfied before it completes execution of the ordered region. A specific dependence is satisfied when a thread that is executing the corresponding iteration encounters an ordered construct with a depend(source) clause.

Execution Model Events The ordered-acquiring event occurs in the task that encounters the ordered construct on entry to the ordered region before it initiates synchronization for the region.

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

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

The doacross-sink event occurs in the task that encounters a ordered construct for each depend(sink:vec) clause after the dependence is fulfilled.

The doacross-source event occurs in the task that encounters a ordered construct with a depend(source:vec) clause before signaling the dependence to be fulfilled.

Tool Callbacks A thread dispatches a registered ompt_callback_mutex_acquire callback for each occurrence of an ordered-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 an ordered-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 with ompt_mutex_ordered as the kind argument if practical, although a less specific kind may be used, for each occurrence of an ordered-released event in that thread. This callback has the type signature ompt_callback_mutex_t and occurs in the task that encounters the atomic construct.

A thread dispatches a registered ompt_callback_dependences callback with all vector entries listed as ompt_dependence_type_sink in the deps argument for each occurrence of a doacross-sink event in that thread. A thread dispatches a registered ompt_callback_dependences callback with all vector entries listed as ompt_dependence_type_source in the deps argument for each occurrence of a doacross-source event in that thread. These callbacks have the type signature ompt_callback_dependences_t.

RestrictionsRestrictions to the ordered construct are as follows:

SVG-Viewer needed.

SVG-Viewer needed.

Cross References