I'm still not sure I follow. Where does the "ton of code" come in? The boilerplate code around spawning new threads? The painfulness of that task varies widely amongst OS-level threading primitives, user-level thread libraries, and other programming models that let you do tasks with dependences like Cilk http://supertech.csail.mit.edu/cilk/ or TBB http://www.threadingbuildingblocks.org/ .
Personally, if I have a DAG of tasks to do, I prefer to encode that DAG in the structure of my code by breaking independent chains into separate tasks/threads/whatever and feeding that to some piece of software to do the scheduling for me, rather than roll my own scheduling in a potentially bug-prone and unscalable way. For the example shown, either is perfectly fine, but if you have hundreds of outstanding jobs with a more complex dependence structure, I'd rather not deal with scheduling myself.
Personally, if I have a DAG of tasks to do, I prefer to encode that DAG in the structure of my code by breaking independent chains into separate tasks/threads/whatever and feeding that to some piece of software to do the scheduling for me, rather than roll my own scheduling in a potentially bug-prone and unscalable way. For the example shown, either is perfectly fine, but if you have hundreds of outstanding jobs with a more complex dependence structure, I'd rather not deal with scheduling myself.