Previous | Next --- Slide 32 of 64
Back to Lecture Thumbnails
Qiaoyu

Does it mean we can be in this situation?
  |______
  |           |
  |           |
-----         |
|foo|     |
-----         |
  |          |
-----         |
|bar|     |
-----         |
  |______|
  |
Correct me if I am wrong, cilk_spawn will just add foo() to the pool of works and make it possible assign foo() and bar() running on different thread. So it does not imply that cilk_spawn() function() will create an additional thread and absolutely assign the work of running function() on that thread. If this is the case, why should we leave this kind of ambiguity? I mean if we can let the thread do exactly what we want, will that be better to design a better strategy?

ykt

So, I guess this is where the entire abstraction vs implementation comes into the picture. When we say cilk_spawn, we are just saying that this is an independent piece of work that can be performed concurrently. It is upto the implementation to decide how to actually execute it. Implementation-wise, from what I've understood, cilk will have as many threads running as there are cores available. Here I guess we are assuming that we have two threads available, and since one thread will be doing absolutely nothing, it should grab the work from the other thread's queue when it is available.