This seems very similar to rust's async await model where the execution contexts are executed by 'executors'. The context in which I saw it used was in a web server where most of the time is waiting, and threads take up a non negligible amount of memory, so you can't easily spin up a thread for each connection. Does cilk work in the same way where each execution context is designed to be more lightweight than a thread or is it more designed less as a replacement to threads and more of a work distribution framework?

How is using cilk spawn and cilk sync different from using a thread pool? From my perspective, they seems similar, as cilk spawn basically spawn a thread to execute a function that is independent?

Can we interpret “execution contexts in the machine” as the number of hardware threads supported by the machine?

@student1, from an implementation perspective, the Cilk runtime and thread pools are likely quite similar. However, the abstraction provided by Cilk does not directly imply the use of a thread pool (we could imagine alternative implementations like a single-threaded asynchronous structure) and the abstraction also allows us to stop thinking about threads directly.

@czh Yes, I believe from a hardware perspective, execution contexts and the number of supported hardware threads refer to the same thing because they both imply hardware resources that store data for multiple threads at once.