Chapter 14 — seq vs. par vs. par_unseq
The execution policy changes how an algorithm's work gets scheduled, never what the answer is.
The full source for this example lives in
examples/concurrency/14-par-sort-reduce/— clone the repo,cdin, and./demo.sh.
Chapter reference: Doc 14 — Parallel Algorithms and Execution Policies
What it shows
One fixed pseudo-random dataset is sorted with std::sort and reduced with std::transform_reduce under seq, par, and par_unseq, hashing the sorted output and summing the reduction with an exactly associative integer combiner so the result is bit-identical regardless of evaluation order. The sort hash and reduction sum matching exactly across all three policies, every trial, is the hard assertion — any divergence is a correctness bug, independent of which policy ran faster. A sched_getcpu()-union technique records which CPUs the reduction actually touched; par using more than one CPU is reported as a soft signal, since the standard permits but does not require a parallel STL implementation to split any particular workload.
Running it
cd examples/concurrency/14-par-sort-reduce
./demo.sh # build + run par_sort_reduce + verify.lua (--cpus=4)
./demo.sh --clean # remove the image