3 ms·
Should that be synchronous instead of asynchronous, and vice-versa? Maybe I'm misunderstanding.
by sparky 17y ago
Should that be synchronous instead of asynchronous, and vice-versa? Maybe I'm misunderstanding.
- etherealG 17y agoagreed, doesn't waiting for request to finish completely before sending response imply synchronous not async?
- axod 17y agoyes, 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.