Work-Sharing Constructs

A work-sharing construct distributes the implementation of the associated region between the members of the team that encounters it. A work-sharing construct do not launch new threads.

OpenMP describes three work-sharing constructs: sections, for, and single.

In all of these constructs, there is an implicit barrier at the end of the construct unless a nowait clause is included.

(a) Sections

The sections construct is a no iterative work-sharing create that causes the structured blocks to be shared between the threads in team. Every structured block is implemented once by one of the threads in the team. The syntax of the sections construct is:

#pragma omp sections [set of clauses.]

{

#pragma omp section

structured-bloc

#pragma omp section structured-block

.

.

.

}

The clause is one of the following:

private(list)

 firstprivate(list)

 lastprivate(list)

 reduction(operator: list)

 nowait

(i) Lastprivate Clause

The lastprivate clause states one or more list items to be private to a thread, and causes the corresponding original list item to be updated after the end of the region. The syntax of the lastprivate clause is:

Lastprivate (list)

(ii) Reduction Clause

The reduction clause shows an operator and one or more list items. For every list item, a private copy is created on each thread, and is initialized appropriately for the operator. After the ending of the region, the original list item is updated with the values of the private copies using the particular operator. The syntax of the reduction clause is :

reduction (operator:list)

 (b) For Loop Construct

The loop construct causes the for loop to be divided into parts and parts shared between threads in the team. The syntax of the loop construct is :

#pragma omp for [set of clauses. ]

for-loop

The clause is one of the following:

private(list)

 firstprivate(list)

 lastprivate(list)

reduction(operator: list)

(c) Single Construct

The single construct shows that the associated structured block is implemented by only one thread in the team (not necessarily the master thread). The other threads in the team do not implement the block, and wait at an implicit barrier at the end of the single construct, unless a nowait clause is specified.The syntax of the single construct is as follows:

#pragma omp single [set of clauses]

structured-block

The clause is one of the following:

private(list)

firstprivate(list)

 copyprivate(list)

nowait

(iii) Combined Parallel Work-sharing Constructs

Combined parallel work-sharing constructs are shortcuts for describe a work-sharing construct nested immediately inside a parallel construct. The combined parallel work- sharing constructs allow certain clauses which are permitted on both work-sharing constructs and on parallel constructs. OpenMP shows the two combined parallel work- sharing constructs:  parallel loop construct, and parallel sections construct.

(a) Parallel Loop Construct

The parallel loop construct is a shortcut for shows a parallel construct containing one loop construct and no other statements. The syntax of the parallel loop construct is :

#pragma omp parallel for [set of clauses]

for-loop

(a)  Parallel Sections Construct

The parallel sections construct is a shortcut for showing a parallel construct containing one sections construct and no other statements. The syntax of the parallel sections construct is:

#pragma omp parallel sections [ set of clauses]

{

[#pragma omp section ]

structured-block [#pragma omp section structured-block ]

...

}

In the following example, routines xaxis, yaxis, and zaxis can be implemented concurrently. The first section directive is optional. Note that all the section directives need to appear in the parallel sections construct.

(iv) Master Construct

The master directive has the following general form:

#pragma omp master structured_block

It causes the master thread to implement the structured block. Other threads encountering this directive will ignore it and the associated structured block, and will go on. In the example, the master keeps track of how much iteration has been implemented and prints out a progress report. The other threads leave the master region without waiting.

(v) Critical Directive

The critical directive allows one thread implement the associated structured block. When more than one threads reach the critical directive, they will wait up to no other thread is

Implementing the similar critical section (one with the same name), and then one thread will proceed to implement the structured block. The syntax of the critical directive is

#pragma omp critical [name]

structured_block

name is optional. All critical segments with no name are considered to be one undefined name.

(vi) Barrier Directive

The syntax of the barrier directive is

#pragma omp barrier

When a thread arrives at the barrier it waits until all threads have arrived the barrier and then they all go on together. There are restrictions on the placement of barrier directive in a program. The barrier directive may only be placed in the program at a position where deleting or ignoring the directive would result in a program with correct syntax.

(vii) Atomic Directive

The atomic directive makes sure that a definite storage location is updated atomically, quite than exposing it to the possibility of multiple, concurrent writing threads. The syntax of atomic directive is:

#pragma omp atomic expression_statement

The atomic directive executes a critical section efficiently when the critical section easily updates a variable by arithmetic operation defined by expression_statement.

(viii) Ordered directive

This directive is used in conjunction with for and parallel for directives to cause an iteration to be implemented in the order that it would have occurred if written as a sequential loop. The syntax of the ordered construct is as follows:

#pragma omp ordered new-line structured-block