<ahref="#PERTIntroduction">What is a PERT Chart?</a>
</li>
<liclass="level1">
<ahref="#PERTProblem">A Concrete Project</a>
</li>
<liclass="level1">
<ahref="#PERTCriticalPath">Finding the Critical Path</a>
</li>
<liclass="level1">
<ahref="#PERTImplementation">Implementation</a>
</li>
<liclass="level1">
<ahref="#PERTDesignPoints">Design Points</a>
</li>
</ul>
</div>
<divclass="textblock"><p>We study how to express a <em>PERT</em> (Program Evaluation and Review Technique) <em>chart</em> as a static <aclass="el" href="classtf_1_1Taskflow.html" title="class to create a taskflow object">tf::Taskflow</a> and use the task graph to automatically parallelize a project schedule while respecting all precedence constraints. This example shows how project-management scheduling theory maps directly onto Taskflow's task dependency model, and why a static task graph is the right tool when the dependency structure is fully known before execution begins.</p>
<h1><aclass="anchor" id="PERTIntroduction"></a>
What is a PERT Chart?</h1>
<p>PERT (Program Evaluation and Review Technique) is a project-management method that represents a project as a directed acyclic graph. Each node is a task with an estimated duration. Each directed edge means this task cannot begin until its predecessor is complete. The goal is to finish the entire project as fast as possible by running independent tasks in parallel, while respecting every dependency.</p>
<p>The key quantity in PERT analysis is the <em>critical</em><em>path:</em> the longest chain of dependent tasks from project start to project finish. No matter how many workers are available, the project cannot complete faster than the sum of durations along the critical path. Every task on the critical path has zero slack—any delay to it delays the whole project. Tasks off the critical path have positive slack and can be deferred or slowed without affecting the project deadline.</p>
<p>PERT analysis is classically done on paper or in a spreadsheet. The observation at the heart of this example is that a PERT chart <em>is</em> a task dependency graph, and Taskflow can execute it directly: tasks that are independent in the project schedule run in parallel on separate CPU cores, exactly as a project manager would assign them to separate teams.</p>
<h1><aclass="anchor" id="PERTProblem"></a>
A Concrete Project</h1>
<p>Consider a nine-task software release project. Each task has an estimated duration in days and a set of prerequisites:</p>
<tdclass="markdownTableBodyLeft">A </td><tdclass="markdownTableBodyLeft">Requirements gathering </td><tdclass="markdownTableBodyCenter">3 d </td><tdclass="markdownTableBodyLeft">— </td></tr>
<trclass="markdownTableRowEven">
<tdclass="markdownTableBodyLeft">B </td><tdclass="markdownTableBodyLeft">System architecture </td><tdclass="markdownTableBodyCenter">2 d </td><tdclass="markdownTableBodyLeft">A </td></tr>
<trclass="markdownTableRowOdd">
<tdclass="markdownTableBodyLeft">C </td><tdclass="markdownTableBodyLeft">UI mockups </td><tdclass="markdownTableBodyCenter">2 d </td><tdclass="markdownTableBodyLeft">A </td></tr>
<trclass="markdownTableRowEven">
<tdclass="markdownTableBodyLeft">D </td><tdclass="markdownTableBodyLeft">Backend API </td><tdclass="markdownTableBodyCenter">3 d </td><tdclass="markdownTableBodyLeft">B </td></tr>
<trclass="markdownTableRowOdd">
<tdclass="markdownTableBodyLeft">E </td><tdclass="markdownTableBodyLeft">Frontend implementation </td><tdclass="markdownTableBodyCenter">4 d </td><tdclass="markdownTableBodyLeft">C </td></tr>
<trclass="markdownTableRowEven">
<tdclass="markdownTableBodyLeft">F </td><tdclass="markdownTableBodyLeft">Database schema </td><tdclass="markdownTableBodyCenter">2 d </td><tdclass="markdownTableBodyLeft">B </td></tr>
<trclass="markdownTableRowOdd">
<tdclass="markdownTableBodyLeft">G </td><tdclass="markdownTableBodyLeft">Integration </td><tdclass="markdownTableBodyCenter">2 d </td><tdclass="markdownTableBodyLeft">D, E, F </td></tr>
<trclass="markdownTableRowEven">
<tdclass="markdownTableBodyLeft">H </td><tdclass="markdownTableBodyLeft">QA testing </td><tdclass="markdownTableBodyCenter">3 d </td><tdclass="markdownTableBodyLeft">G </td></tr>
<trclass="markdownTableRowOdd">
<tdclass="markdownTableBodyLeft">I </td><tdclass="markdownTableBodyLeft">Deployment </td><tdclass="markdownTableBodyCenter">1 d </td><tdclass="markdownTableBodyLeft">H </td></tr>
</table>
<p>The dependency graph is shown below. Tasks are coloured by phase: blue for discovery, green for design, yellow for implementation, orange for integration and test, and red for delivery.</p>
<divclass="dotgraph">
<iframescrolling="no" frameborder="0" src="dot_pert_dag.svg" width="936" height="215"><p><b>This browser is not able to show SVG: try Firefox, Chrome, Safari, or Opera instead.</b></p></iframe></div>
<p>The graph has a single source (A) and a single sink (I). After A completes, B and C are both unblocked and can run on separate cores simultaneously. After B completes, D and F are both unblocked. G cannot start until D, E, and F have all finished.</p>
<h1><aclass="anchor" id="PERTCriticalPath"></a>
Finding the Critical Path</h1>
<p>The critical path is found by a forward pass through the graph: for each task, the <em>earliest</em><em>start</em> (ES) is the maximum earliest finish (EF) among all its predecessors, and the earliest finish is ES plus the task duration.</p>
<divclass="fragment"><divclass="line">Forward pass (ES = max EF of predecessors, EF = ES + duration):</div>
<divclass="line"> A: ES = 0, EF = 0 + 3 = 3</div>
<divclass="line"> B: ES = 3, EF = 3 + 2 = 5 (predecessor: A)</div>
<divclass="line"> C: ES = 3, EF = 3 + 2 = 5 (predecessor: A)</div>
<divclass="line"> D: ES = 5, EF = 5 + 3 = 8 (predecessor: B)</div>
<divclass="line"> E: ES = 5, EF = 5 + 4 = 9 (predecessor: C)</div>
<divclass="line"> F: ES = 5, EF = 5 + 2 = 7 (predecessor: B)</div>
<divclass="line"> G: ES = 9, EF = 9 + 2 = 11 (predecessors: D, E, F — max EF is E's 9)</div>
<divclass="line"> H: ES = 11, EF = 11 + 3 = 14 (predecessor: G)</div>
<divclass="line"> I: ES = 14, EF = 14 + 1 = 15 (predecessor: H)</div>
</div><!-- fragment --><p>The project takes <b>15</b><b>days</b> in the best case. A backward pass then computes the latest start (LS) and latest finish (LF) for each task, and slack = LS − ES:</p>
<divclass="fragment"><divclass="line">Backward pass and slack:</div>
</div><!-- fragment --><p>The critical path is <b>A -> C -> E -> G -> H -> I</b>. Tasks B, D, and F each have positive slack: B and D can each slip by one day without affecting the deadline, and F can slip by two days. The figure below highlights the critical path in red and annotates each task with its earliest start, earliest finish, and slack.</p>
<divclass="dotgraph">
<iframescrolling="no" frameborder="0" src="dot_pert_critical_path.svg" width="1067" height="240"><p><b>This browser is not able to show SVG: try Firefox, Chrome, Safari, or Opera instead.</b></p></iframe></div>
<h1><aclass="anchor" id="PERTImplementation"></a>
Implementation</h1>
<p>The mapping from a PERT chart to a <aclass="el" href="classtf_1_1Taskflow.html" title="class to create a taskflow object">tf::Taskflow</a> is direct: one task per project activity, one <code>precede</code> call per dependency edge. We represent each project activity as a <code><aclass="el" href="classtf_1_1Task.html" title="class to create a task handle over a taskflow node">Task</a></code> struct carrying its name, duration, and the earliest-start time recorded at runtime for verification:</p>
<divclass="line"> A.<aclass="code hl_function" href="classtf_1_1Task.html#a8c78c453295a553c1c016e4062da8588">precede</a>(B, C); <spanclass="comment">// B and C both wait for A</span></div>
<divclass="line"> B.<aclass="code hl_function" href="classtf_1_1Task.html#a8c78c453295a553c1c016e4062da8588">precede</a>(D, F); <spanclass="comment">// D and F both wait for B</span></div>
<divclass="line"> C.<aclass="code hl_function" href="classtf_1_1Task.html#a8c78c453295a553c1c016e4062da8588">precede</a>(E); <spanclass="comment">// E waits for C</span></div>
<divclass="line"> G.<aclass="code hl_function" href="classtf_1_1Task.html#a331b1b726555072e7c7d10941257f664">succeed</a>(D, E, F); <spanclass="comment">// G waits for all three</span></div>
<divclass="ttc" id="aclasstf_1_1Executor_html"><divclass="ttname"><ahref="classtf_1_1Executor.html">tf::Executor</a></div><divclass="ttdoc">class to create an executor</div><divclass="ttdef"><b>Definition</b> executor.hpp:62</div></div>
<divclass="ttc" id="aclasstf_1_1Executor_html_a519777f5783981d534e9e53b99712069"><divclass="ttname"><ahref="classtf_1_1Executor.html#a519777f5783981d534e9e53b99712069">tf::Executor::run</a></div><divclass="ttdeci">tf::Future< void > run(Taskflow &taskflow)</div><divclass="ttdoc">runs a taskflow once</div></div>
<divclass="ttc" id="aclasstf_1_1Task_html_a331b1b726555072e7c7d10941257f664"><divclass="ttname"><ahref="classtf_1_1Task.html#a331b1b726555072e7c7d10941257f664">tf::Task::succeed</a></div><divclass="ttdeci">Task & succeed(Ts &&... tasks)</div><divclass="ttdoc">adds precedence links from other tasks to this</div><divclass="ttdef"><b>Definition</b> task.hpp:1313</div></div>
<divclass="ttc" id="aclasstf_1_1Task_html_a8c78c453295a553c1c016e4062da8588"><divclass="ttname"><ahref="classtf_1_1Task.html#a8c78c453295a553c1c016e4062da8588">tf::Task::precede</a></div><divclass="ttdeci">Task & precede(Ts &&... tasks)</div><divclass="ttdoc">adds precedence links from this to other tasks</div><divclass="ttdef"><b>Definition</b> task.hpp:1305</div></div>
<divclass="ttc" id="aclasstf_1_1Taskflow_html"><divclass="ttname"><ahref="classtf_1_1Taskflow.html">tf::Taskflow</a></div><divclass="ttdoc">class to create a taskflow object</div><divclass="ttdef"><b>Definition</b> taskflow.hpp:64</div></div>
</div><!-- fragment --><p>The expected output (with a 4-worker executor) is:</p>
</div><!-- fragment --><p>Observed earliest-start times match the theoretical values computed by the forward pass. B and C both start at t=3 on separate workers; D, E, and F all start at t=5 on separate workers; G is held until t=9 when the slowest of its three predecessors (E, finishing at t=9) completes.</p>
<p>The task graph that Taskflow constructs and executes is:</p>
<divclass="dotgraph">
<iframescrolling="no" frameborder="0" src="dot_pert_taskflow.svg" width="756" height="187"><p><b>This browser is not able to show SVG: try Firefox, Chrome, Safari, or Opera instead.</b></p></iframe></div>
<h1><aclass="anchor" id="PERTDesignPoints"></a>
Design Points</h1>
<p>Several aspects of this example apply broadly to any static-dependency workflow, not just project scheduling:</p>
<ul>
<li>The PERT graph and the <aclass="el" href="classtf_1_1Taskflow.html" title="class to create a taskflow object">tf::Taskflow</a> are the same object: There is no translation step between the project plan and the parallel program. The dependency edges written as <code>A.precede(B,C)</code>, <code>B.precede(D,F)</code>, and so on are simultaneously the project schedule and the task graph the executor runs. Adding, removing, or reordering a dependency changes both the logical plan and the runtime behaviour in a single edit.</li>
<li>Static construction gives the scheduler full visibility: All tasks and all edges are established before <code>executor.run</code> is called. The scheduler sees the complete graph from the start and can make globally informed decisions—for example, prioritising tasks on the critical path (A, C, E, G, H, I) over tasks with positive slack (B, D, F). A dynamic approach that spawned successors only as each task completed would deny the scheduler this global view, potentially leaving workers idle during the early steps when B, C, D, E, and F are all available.</li>
<li><code>succeed</code> is the mirror of <code>precede</code>, not a different concept: The line <code>G.succeed(D,E,F)</code> is exactly equivalent to writing <code>D.precede(G)</code>, <code>E.precede(G)</code>, <code>F.precede(G)</code> in three separate calls. Use whichever reads more naturally for the task at hand: <code>precede</code> is convenient when writing from a predecessor's perspective ("after me,
run these"), and <code>succeed</code> is convenient when writing from a successor's perspective ("before me, require these"). In a PERT chart, the join task G is the natural place to state its own prerequisites, so <code>succeed</code> reads more clearly there.</li>
<li>Task naming is load-bearing for diagnostics: Every task is given a human-readable name via <code></code>.name(). This name appears verbatim in <code>taskflow.dump()</code> (which emits a Graphviz-compatible description of the graph), in the Taskflow profiler timeline, and in any error or assertion messages. In a project-scheduling context, naming each task after its activity makes the profiler output directly interpretable as a Gantt chart, showing exactly which activities ran in parallel and where the critical path was actually observed.</li>
<li>Slack directly measures scheduling flexibility: Tasks B (slack=1), D (slack=1), and F (slack=2) can start later than their earliest start without delaying the project. In a real system, this slack translates directly to scheduling latitude: the executor can delay these tasks—for example, to co-locate them with other work on the same NUMA node—without violating the project deadline. Taskflow's work-stealing scheduler exploits this implicitly: it will pick up B, D, or F whenever a worker becomes free, without the programmer having to annotate priorities or affinities manually.</li>
</ul>
<dlclass="section note"><dt>Note</dt><dd>This example uses <code>std::this_thread::sleep_for</code> to simulate task durations, which is appropriate for illustrating scheduling behaviour but not for production use. In a real project executor, each task lambda would dispatch the actual computational work for that activity—compiling a source file, running a test suite, transferring a dataset—and the sleep would be replaced by that work. The dependency wiring and scheduling logic remain identical regardless of what the task bodies actually do. </dd></dl>
</div></div><!-- contents -->
</div><!-- PageDoc -->
</div><!-- doc-content -->
<!-- HTML footer for doxygen 1.13.1-->
<!-- start footer part -->
<divid="nav-path" class="navpath"><!-- id is needed for treeview function! -->
<ul>
<liclass="navelem"><aclass="el" href="Examples.html">Learning from Examples</a></li>
<liclass="footer">
Maintained by <ahref="https://tsung-wei-huang.github.io/">Dr. Tsung-Wei Huang</a>
—
Generated by <ahref="https://www.doxygen.org/index.html"><imgclass="footer" src="doxygen.svg" width="104" height="31" alt="doxygen"/></a> 1.13.1