Cilkscreen reported a data race in our code. The data race was between the dereference
of a struct pointer so that we could pass a struct to a spawned cilk strand, and a
modificaton to the struct through the pointer after the spawn. We thought that the
arguments to a spawned cilk strand would be evaluation before the strand is created.
We found that cilkscreen reports the data race in the deref.cilk program but not the
deref_works.cilk program. The difference is that we force the struct pointer dereference
before the cilk_spawn rather than in the cilk_spawn function call.
When are the arguments to a spawned cilk strand bound?
If the arguments are bound before spawning the cilk strand, then the deref.cilk program
is correct. However, cilkscreen says that we have a data race between the creation of the
arguments to the spawned function f and the zero of the element on the subsequent line.
This indicates a bug in either the cilk compiler or in cilkscreen.
If the arguments are bound after spawning the cilk strand, the the deref.cilk program
is not correct. However, the cilk programmer's guide is not specific about when
pass by value arguments are evaluated.
If one changes the argument type from a "struct p" to an int, then cilkscreen does not
find any issues. This indicates that the cilk compiler does not handle struct arguments
correctly. This is captured in the deref_int.cilk program.