chapel-lang / chapel

a Productive Parallel Programming Language
https://chapel-lang.org
Other
1.78k stars 418 forks source link

How does 'in' forall intent work with nested tasks? #5363

Open vasslitvinov opened 7 years ago

vasslitvinov commented 7 years ago

The semantics of in forall intent is that the shadow variable implicitly refers to the implicit formal of the task function in the corresponding parallel iterator (leader or standalone) that executes the current yield statement. If the yield is executed outside any task constructs, the shadow variable refers to the implicit formal of the parallel iterator itself. These implicit formals have in intent as well.

This issue seeks to clarify what happens when a task construct follows a yield or visa versa. Specifically, the implicit formal of the task is initialized to:

This question is exemplified by the following code:

proc myiter(param tag==iterKind.standalone) {

  yield 1; // a yield outside any task constructs

  coforall ... {
    yield 2;  // inside a task construct,
              // follows a yield outside the task constructs

    coforall ... {
      yield 3;  // inside a child task construct,
                // follows a yield outside the parent task
    }

    yield 4;  // follows yield(s) in task(s) that have completed
  }

  yield 5; // follows yields in some tasks that have completed
}

var x = 10;
forall idx in myiter() with (in x) {
  x += 1;
  writeln("iteration=", idx, " x=", x);
}

If each coforall executes just a single iteration, what should be the output?

iteration=1  x=11
iteration=2  x=12  // or x=11 ?
iteration=3  x=13  // or x=11 ?
iteration=4  x=13  // +1 from iteration=2 ?
iteration=5  x=12  // +1 from iteration=1 ?

Or should x start out with the value 10 for each iteration? For each iteration except 4 and 5?

benharsh commented 7 years ago

My gut reaction is that x should start with the value 10 for each iteration. My sense of in generally is that you get a copy of the original x that you can modify within a certain scope. If changes persisted beyond that scope (the loop body in this case), that would strike me as confusing behavior.