<li><ahref="#CreateARuntimeTask">Create a Runtime Object</a></li>
<li><ahref="#AcquireTheRunningExecutor">Acquire the Running Executor</a></li>
<li><ahref="#RuntimeTaskingRunATaskGraphSynchronously">Run a Task Graph Synchronously</a></li>
<li><ahref="#LearnMoreAboutRuntime">Learn More About Runtime</a></li>
</ul>
</nav>
<p>Taskflow allows you to interact with the scheduling runtime by taking a <em>runtime object</em> as an argument of a task. This is mostly useful for designing specialized parallel algorithms extended from the existing facility of Taskflow.</p><sectionid="CreateARuntimeTask"><h2><ahref="#CreateARuntimeTask">Create a Runtime Object</a></h2><p>Taskflow allows a static task and a condition task to take a referenced <ahref="classtf_1_1Runtime.html" class="m-doc">tf::<wbr/>Runtime</a> object that provides a set of methods to interact with the scheduling runtime. The following example creates a static task that leverages <ahref="classtf_1_1Runtime.html" class="m-doc">tf::<wbr/>Runtime</a> to explicitly schedule a conditioned task which would never run under the normal scheduling circumstance:</p><preclass="m-code"><spanclass="n">tf</span><spanclass="o">::</span><spanclass="n">Task</span><spanclass="w"></span><spanclass="n">A</span><spanclass="p">,</span><spanclass="w"></span><spanclass="n">B</span><spanclass="p">,</span><spanclass="w"></span><spanclass="n">C</span><spanclass="p">,</span><spanclass="w"></span><spanclass="n">D</span><spanclass="p">;</span>
<spanclass="w"></span><spanclass="p">[</span><spanclass="o">&</span><spanclass="n">C</span><spanclass="p">]</span><spanclass="w"></span><spanclass="p">(</span><spanclass="n">tf</span><spanclass="o">::</span><spanclass="n">Runtime</span><spanclass="o">&</span><spanclass="w"></span><spanclass="n">rt</span><spanclass="p">)</span><spanclass="w"></span><spanclass="p">{</span><spanclass="w"></span><spanclass="c1">// C must be captured by reference</span>
</div><p>When the condition task <code>A</code> completes and returns <code>0</code>, the scheduler moves on to task <code>B</code>. Under the normal circumstance, tasks <code>C</code> and <code>D</code> will not run because their conditional dependencies never happen. This can be broken by forcefully scheduling <code>C</code> or/and <code>D</code> via a runtime object of a task that resides in the same graph. Here, task <code>B</code> call <ahref="classtf_1_1Runtime.html#aa7e72cc0f298475195b252c8f1793343" class="m-doc">tf::<wbr/>Runtime::<wbr/>schedule</a> to forcefully run task <code>C</code> even though the weak dependency between <code>A</code> and <code>C</code> will never happen based on the graph structure itself. As a result, we will see both <code>B</code> and <code>C</code> in the output:</p><preclass="m-console"><spanclass="go">B # B leverages a runtime object to schedule C out of its dependency constraint</span>
<spanclass="go">C</span></pre><asideclass="m-note m-warning"><h4>Attention</h4><p>You should only schedule an <em>active</em> task from a runtime object. An active task is a task in a running taskflow. The task may or may not be running, and scheduling that task will immediately put it into the task queue of the worker that is running the runtime object.</p></aside></section><sectionid="AcquireTheRunningExecutor"><h2><ahref="#AcquireTheRunningExecutor">Acquire the Running Executor</a></h2><p>You can acquire the reference to the running executor using <ahref="classtf_1_1Runtime.html#a4ee48a82df1f9758a999d18e6015cec4" class="m-doc">tf::<wbr/>Runtime::<wbr/>executor()</a>. The executor associated with a runtime object is the executor that runs the parent task of that runtime object.</p><preclass="m-code"><spanclass="n">tf</span><spanclass="o">::</span><spanclass="n">Executor</span><spanclass="w"></span><spanclass="n">executor</span><spanclass="p">;</span>
<spanclass="n">executor</span><spanclass="p">.</span><spanclass="n">run</span><spanclass="p">(</span><spanclass="n">taskflow</span><spanclass="p">).</span><spanclass="n">wait</span><spanclass="p">();</span></pre></section><sectionid="RuntimeTaskingRunATaskGraphSynchronously"><h2><ahref="#RuntimeTaskingRunATaskGraphSynchronously">Run a Task Graph Synchronously</a></h2><p>A runtime object can spawn and run a task graph synchronously using <ahref="classtf_1_1Runtime.html#a1c772e90614302024cfa52fa86d75cac" class="m-doc">tf::<wbr/>Runtime::<wbr/>corun</a>. This model allows you to leverage dynamic tasking to execute a parallel workload within a runtime object. You can create a task graph yourself and execute it through a runtime object. This organization avoids repetitive creation of a subflow with the same topology, such as running a runtime object repetitively. The following code performs the same execution logic as the above example but using the given task graph to avoid repetitive creations of a subflow:</p><preclass="m-code"><spanclass="c1">// create a custom graph</span>
<spanclass="n">executor</span><spanclass="p">.</span><spanclass="n">run_n</span><spanclass="p">(</span><spanclass="n">taskflow</span><spanclass="p">,</span><spanclass="w"></span><spanclass="mi">10000</span><spanclass="p">);</span></pre><p>Although <ahref="classtf_1_1Runtime.html#a1c772e90614302024cfa52fa86d75cac" class="m-doc">tf::<wbr/>Runtime::<wbr/>corun</a> blocks until the operation completes, the caller thread (worker) is not preempted (e.g., sleep or holding any lock). Instead, the caller thread joins the work-stealing loop of the executor and leaves whenever the spawned task graph completes. This is different from waiting for a submitted taskflow using tf::Future<T>::wait which blocks the caller thread until the submitted taskflow completes. When multiple submitted taskflows are being waited, their executions can potentially lead to deadlock. For example, the code below creates a taskflow of 1000 tasks with each task running a taskflow of 500 tasks in a blocking fashion:</p><preclass="m-code"><spanclass="n">tf</span><spanclass="o">::</span><spanclass="n">Executor</span><spanclass="w"></span><spanclass="nf">executor</span><spanclass="p">(</span><spanclass="mi">2</span><spanclass="p">);</span>
<spanclass="n">executor</span><spanclass="p">.</span><spanclass="n">run</span><spanclass="p">(</span><spanclass="n">taskflow</span><spanclass="p">).</span><spanclass="n">wait</span><spanclass="p">();</span></pre><p>Using <ahref="classtf_1_1Runtime.html#a1c772e90614302024cfa52fa86d75cac" class="m-doc">tf::<wbr/>Runtime::<wbr/>corun</a> allows each worker to corun these taskflows through its work-stealing loop, thus avoiding deadlock problem caused by blocking wait.</p><preclass="m-code"><spanclass="n">tf</span><spanclass="o">::</span><spanclass="n">Executor</span><spanclass="w"></span><spanclass="nf">executor</span><spanclass="p">(</span><spanclass="mi">2</span><spanclass="p">);</span>
<spanclass="n">executor</span><spanclass="p">.</span><spanclass="n">run</span><spanclass="p">(</span><spanclass="n">taskflow</span><spanclass="p">).</span><spanclass="n">wait</span><spanclass="p">();</span></pre></section><sectionid="LearnMoreAboutRuntime"><h2><ahref="#LearnMoreAboutRuntime">Learn More About Runtime</a></h2><p>Please visit the following pages to learn more about <ahref="classtf_1_1Runtime.html" class="m-doc">tf::<wbr/>Runtime</a>:</p><ul><li><ahref="AsyncTasking.html#LaunchAsynchronousTasksFromARuntime" class="m-doc">Launch Asynchronous Tasks from a Runtime</a></li></ul></section>
</div>
</div>
</div>
</article></main>
<divclass="m-doc-search" id="search">
<ahref="#!" onclick="return hideSearch()"></a>
<divclass="m-container">
<divclass="m-row">
<divclass="m-col-m-8 m-push-m-2">
<divclass="m-doc-search-header m-text m-small">
<div><spanclass="m-label m-default">Tab</span> / <spanclass="m-label m-default">T</span> to search, <spanclass="m-label m-default">Esc</span> to close</div>