Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The difference between tasks and sections is in the time frame in which the code will execute. Sections are enclosed within the <code>sections</code> construct and (unless the <code>nowait</code> clause was specified) threads will not leave it until all sections have been executed:</p> <pre class="lang-none prettyprint-override"><code> [ sections ] Thread 0: -------&lt; section 1 &gt;----&gt;*------ Thread 1: -------&lt; section 2 &gt;*------ Thread 2: ------------------------&gt;*------ ... * Thread N-1: ----------------------&gt;*------ </code></pre> <p>Here <code>N</code> threads encounter a <code>sections</code> construct with two sections, the second taking more time than the first. The first two threads execute one section each. The other <code>N-2</code> threads simply wait at the implicit barrier at the end of the sections construct (show here as <code>*</code>).</p> <p>Tasks are queued and executed whenever possible at the so-called task scheduling points. Under some conditions, the runtime could be allowed to move task between threads, even in the mid of their lifetime. Such tasks are called untied and an untied task might start executing in one thread, then at some scheduling point it might be migrated by the runtime to another thread.</p> <p>Still, tasks and sections are in many ways similar. For example, the following two code fragments achieve essentially the same result:</p> <pre><code>// sections ... #pragma omp sections { #pragma omp section foo(); #pragma omp section bar(); } ... // tasks ... #pragma omp single nowait { #pragma omp task foo(); #pragma omp task bar(); } #pragma omp taskwait ... </code></pre> <p><code>taskwait</code> works very like <code>barrier</code> but for tasks - it ensures that current execution flow will get paused until all queued tasks have been executed. It is a scheduling point, i.e. it allows threads to process tasks. The <code>single</code> construct is needed so that tasks will be created by one thread only. If there was no <code>single</code> construct, each task would get created <code>num_threads</code> times, which might not be what one wants. The <code>nowait</code> clause in the <code>single</code> construct instructs the other threads to not wait until the <code>single</code> construct was executed (i.e. removes the implicit barrier at the end of the <code>single</code> construct). So they hit the <code>taskwait</code> immediately and start processing tasks.</p> <p><code>taskwait</code> is an explicit scheduling point shown here for clarity. There are also implicit scheduling points, most notably inside the barrier synchronisation, no matter if explicit or implicit. Therefore, the above code could also be written simply as:</p> <pre><code>// tasks ... #pragma omp single { #pragma omp task foo(); #pragma omp task bar(); } ... </code></pre> <p>Here is one possible scenario of what might happen if there are three threads:</p> <pre class="lang-none prettyprint-override"><code> +--+--&gt;[ task queue ]--+ | | | | | +-----------+ | | | Thread 0: --&lt; single &gt;-| v |----- Thread 1: --------&gt;|&lt; foo() &gt;|----- Thread 2: --------&gt;|&lt; bar() &gt;|----- </code></pre> <p>Show here within the <code>| ... |</code> is the action of the scheduling point (either the <code>taskwait</code> directive or the implicit barrier). Basically thread <code>1</code> and <code>2</code> suspend what they are doing at that point and start processing tasks from the queue. Once all tasks have been processed, threads resume their normal execution flow. Note that threads <code>1</code> and <code>2</code> might reach the scheduling point before thread <code>0</code> has exited the <code>single</code> construct, so the left <code>|</code>s need not necessary be aligned (this is represented on the diagram above).</p> <p>It might also happen that thread <code>1</code> is able to finish processing the <code>foo()</code> task and request another one even before the other threads are able to request tasks. So both <code>foo()</code> and <code>bar()</code> might get executed by the same thread:</p> <pre class="lang-none prettyprint-override"><code> +--+--&gt;[ task queue ]--+ | | | | | +------------+ | | | Thread 0: --&lt; single &gt;-| v |--- Thread 1: ---------&gt;|&lt; foo() &gt;&lt; bar() &gt;|--- Thread 2: ---------------------&gt;| |--- </code></pre> <p>It is also possible that the singled out thread might execute the second task if thread 2 comes too late:</p> <pre class="lang-none prettyprint-override"><code> +--+--&gt;[ task queue ]--+ | | | | | +------------+ | | | Thread 0: --&lt; single &gt;-| v &lt; bar() &gt;|--- Thread 1: ---------&gt;|&lt; foo() &gt; |--- Thread 2: -----------------&gt;| |--- </code></pre> <p>In some cases the compiler or the OpenMP runtime might even bypass the task queue completely and execute the tasks serially:</p> <pre class="lang-none prettyprint-override"><code>Thread 0: --&lt; single: foo(); bar() &gt;*--- Thread 1: -------------------------&gt;*--- Thread 2: -------------------------&gt;*--- </code></pre> <p>If no task scheduling points are present inside the region's code, the OpenMP runtime might start the tasks whenever it deems appropriate. For example it is possible that all tasks are deferred until the barrier at the end of the <code>parallel</code> region is reached.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload