Hi Damian -
A tiny bit of follow-up is inline below:
That expands my understanding greatly.
Your excellent explanation belongs in the documentation somewhere.
If you can think of a good place to add it - feel free to make a PR
pasting it in to documentation somewhere that makes sense to
you, and we can, in the PR review process, get it to something
that renders reasonably well & makes sense to me as well.
> In your example, a task calling `putStage` could, on a non-x86 system,
> end up storing the value of `stage[i]` in a per-core cache somewhere,
> (let's say, L1 cache, or a write reorder buffer), and put
> off committing it to memory indefinitely. As a result, the parallel
> program would have a load imbalance problem since the current value
> of this variable isn't being communicated to the other tasks.
Understood. If I update a column of a matrix in one core in some parallel
task T, I would still hope that if subsequently, i.e. in a serial sense
and after the task T has finished, I try and read that same column of the
matrix in another core in another parallel task T', I see only the updated
column.
As I said, I assume that a program spawing 2 tasks, say T1 and T2 updating
columns 1 and 2 respectively of a matrix, can be assured on completion of
both T1 and T2 that any subsequent tasks will see only the values written
by T1 and T2 into the matrix.
Yes. The MCM chapter of the spec says this:
> Chapel’s fork-join constructs introduce additional order dependencies.
> Operations within a task cannot behave as though they started before the task
> started. Similarly, all operations in a task must appear to be completed to a
> parent task when the parent task joins with that task.
https://chapel-lang.org/docs/language/spec/memory-consistency-model.html
I view your questions above as rephrasing / corollary to the same idea.
Best,
-michael
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
