3 ms·
yes, which is a silly way to program. I'm not sure why there's any confusion :/ == Sync == Thread 1: Do A -> block -> Do B Thread 2: Do C -> block -> Do D eg
by axod 17y ago
yes, which is a silly way to program. I'm not sure why there's any confusion :/
== Sync ==
Thread 1: Do A -> block -> Do B
Thread 2: Do C -> block -> Do D
eg Tell the OS to execute your code in random order, then build a ton of code to cope with that.
== async ==
while(true) {
// do some of A, or if that's complete, do some of B
// do some of C, or if that's complete, do some of D
}
- sparky 17y agoI'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/ http://supertech.csail.mit.edu/cilk/ or TBB http://www.threadingbuildingblocks.org/ 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.