I'm looking for clarification of something I found a bit ambiguous in the docs.
My code is using the usual recursive structure, and I have a reducer at each (parallel) level. Then,
* at the beginning of each spawned function 'A' I read some values from that worker's view of the reducer
* 'A' calls another function that recursively spawns some more calls to 'A'.
* then I update the values in the worker's view of the reducer.
Does the reducer have the same view in the read & write in the first & last op?
I had assumed it did, but the "Mapping Strands to Workers" section in the Cilk Plus docs says:
cilk_sync, execution may proceed on any worker that executed a
strand that entered the sync."
And cilkscreen is reporting a race between the first & last ops (though it reports other things that seem invalid), so maybe someone could steal the initial worker & be reading values from it while I'm writing them in the final worker? [Edit: I was actually saving the pointer to the initial view, and then updating that pointer, instead of getting the pointer from the current view; hence my concern about races. But avoiding this (i.e. using the view every time) actually isn't removing the race as far as cilkscreen is concerned]
I say I found this a bit ambiguous because e.g. a bit earlier on that page it says "there are one of two ways that this
program may execute" and doesn't consider this particular option. Not that this is incorrect, but it doesn't correct any prior assumptions I may have had :).
[Edit: also, if this is the case, is there any way to avoid this - i.e. to use the same reducer view after the sync?]
Thanks again for your help.
P.S. On a related note, how would TBB behave in this scenario, where instead of cilk_spawn/sync one uses tbb::task_group::run() and ::wait()? Can the post-wait() continuation be stolen? Wrong forum I know, but should my mental model be different?