We study how to express a PERT (Program Evaluation and Review Technique) chart as a static tf::Taskflow 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.
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.
The key quantity in PERT analysis is the critical path: 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.
PERT analysis is classically done on paper or in a spreadsheet. The observation at the heart of this example is that a PERT chart is 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.
Consider a nine-task software release project. Each task has an estimated duration in days and a set of prerequisites:
| Task | Description | Duration | Prerequisites |
|---|---|---|---|
| A | Requirements gathering | 3 d | — |
| B | System architecture | 2 d | A |
| C | UI mockups | 2 d | A |
| D | Backend API | 3 d | B |
| E | Frontend implementation | 4 d | C |
| F | Database schema | 2 d | B |
| G | Integration | 2 d | D, E, F |
| H | QA testing | 3 d | G |
| I | Deployment | 1 d | H |
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.
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.
The critical path is found by a forward pass through the graph: for each task, the earliest start (ES) is the maximum earliest finish (EF) among all its predecessors, and the earliest finish is ES plus the task duration.
The project takes 15 days in the best case. A backward pass then computes the latest start (LS) and latest finish (LF) for each task, and slack = LS − ES:
The critical path is A -> C -> E -> G -> H -> I. 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.
The mapping from a PERT chart to a tf::Taskflow is direct: one task per project activity, one precede call per dependency edge. We represent each project activity as a Task struct carrying its name, duration, and the earliest-start time recorded at runtime for verification:
The expected output (with a 4-worker executor) is:
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.
The task graph that Taskflow constructs and executes is:
Several aspects of this example apply broadly to any static-dependency workflow, not just project scheduling:
A.precede(B,C), B.precede(D,F), 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.executor.run 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.succeed is the mirror of precede, not a different concept: The line G.succeed(D,E,F) is exactly equivalent to writing D.precede(G), E.precede(G), F.precede(G) in three separate calls. Use whichever reads more naturally for the task at hand: precede is convenient when writing from a predecessor's perspective ("after me,
run these"), and succeed 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 succeed reads more clearly there.taskflow.dump() (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.std::this_thread::sleep_for 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. 
1.12.0