It seems like what's illustrated here is continuation-first, with thread 0 spawning tasks (pushing to queue) before executing any of them.

oh nvm - it's the opposite! i was misinterpreting the diagram. it's pushing the equivalent of the call to quick_sort(middle+1, last) (this is continuation) onto the queue, while executing what's in the cilk_spawn call (begin, middle).

I was a bit confused on this code -- why don't we have to call cilk_sync at the end of the function? Is it called by default when a function returns?

@probreather101, that's right. According to slide 26, every function that contains the cilk_spawn keyword has an implicit cilk_sync at the end of it. I think it is injected by the Cilk compiler at compile time.

Does it only call when a function returns? I imagine that we could totally want to paralellize a certain portion of the function and then make the remainder sequential, i.e perform some operation on the aggregate sum

I am a bit confused by what order the continuations are pushed onto the queue, and then which order they are removed from it in this instance. To my understanding it would be 0-100 executed first, then 101-200 added to the queue, then 0-100 would be split into 0-50, 51-100 where 0-50 would be executed and 51-100 pushed to the queue. However the ordering of the queue doesn't seem to demonstrated that (unless objects are pushed onto this queue more like a stack).

@martigp In slide 48 it's discussed that local threads push/pop from the bottom of the queue (treating queue as a stack) while remote threads steal from the top of the queue (treating queue like a queue)