We've talked previously in this forum of using a shared atomic to abort a set of tasks executing a split loop, but I have trouble understandingthe problem statement here. On the one hand, the goal is to race a discrete set of tests in parallel; on the other, there's arequirement to abort "generated ... additional tasks." The former suggests a set of single threaded experiments, no more alternatives than there are HW threads to use as vehicles: each proceeds independently and the first one finishing aborts the others. (Sounds a lot like processes affinitized to separate processors.) The latter suggests that the experiments themselves are threaded and need to be cleared from the task tree. But tasks arescheduled unfairly in TBB--not a good environment for a race.
Suppose we encapsulatea set of experiments as sibling tasks and call the scheduler. The available HW threads will each take one of the available siblings, do whatever task splitting is available to it, then proceed with the work. Experiments entrusted to other sibling tasks not in that firstsubsetwill langish in the treeas greedy scheduling has each thread working its own subtree of tasks. Marking completion of one of the experiments in the test set could be done by the method mentioned above, but because of greedy scheduling,some experiments in the cohort may not have even been started.