For anyone familar with Golang, I find cilk parallelism paradigm very similar to its WaitGroup synchronization primitive where each goroutine (conceptually similar to thread) can be spawned concurrently and waited on each other like the cilk_sync command

Would the execution be different if we called the buzz() function before the three cilk_spawn fn() calls in the final example? Is this reverse ordering even allowed?

@thepurplecow I think that the invariant for Cilk Plus to work is that all threads should be independent. Considering that, the order with which they are spawned doesn't matter.

I always find having invariants in an algorithm, computer science topic to be very helpful for understanding it.

I found it interesting how a valid implementation of cilk could just ignore all the cilk_spawns and cilk_syncs, instead just calling the functions sequentially as if they were regular serial code. In particular, it's important that the result of any "real" cilk implementation results in the exact same output as if things were just executed sequentially.

Important point: instructions after a cilk_sync call may depend on any spawned functions before the call. clik_sync() is basically a guarantee that all clik_spawned functions have been completed by the scheduler by that time.

Cilk does not require spawned functions to run concurrently but rather asynchronously, but does this mean that child/caller function are run on the same thread or on different threads. Or does this not matter at all? Thanks!