charmplusplus
Define and document semantics of dynamic Insertion in Chare arrays wrt broadcasts and reductions
Original issue: https://charm.cs.illinois.edu/redmine/issues/49
Define the semantics of dynamic insertion, make modifications in Charm to adhere to those semantics, and document it.
Original date: 2013-02-18 03:15:26
So, the meeting on this happened, and it seemed that the consensus settled on "application developers are responsible for ensuring that reductions and dynamic insertion do not overlap". I suggest that this restriction should be documented in the manual section regarding dynamic array element insertion, and referenced in the section on array reductions.
Sanjay, please re-assign this to someone to write.
Original date: 2013-03-15 21:42:07
As discussed in core group, the general semantics should be "don't overlap reductions with insertion", along with an option to specify some sort of token to match an insertion to a specific reduction in which it should participate.
Original date: 2015-12-15 20:32:52
I recently wrote some code for my thesis project that relies on the undocumented semantics of our implementation for reductions. I have a single chare array in which one set of elements are dynamically inserting a later set of elements. I need all of the elements to be on the same page in terms of reductions. Here's what I did:
- all of the pre-existing elements call
contribute()before making an insertion call - that
contribute()call ensures that all of the inserted elements see and are stamped with the same reduction in progress - neither the old nor new elements can safely contribute to a later reduction until we are certain that all of the insertion calls have been made (but not necessarily that the objects have actually been constructed)
- the early reduction is completed solely from the contributions of the old elements, because all new elements are stamped one past it
- that reduction targets a broadcast to the array telling everyone that it's now safe to go on.
Original date: 2018-04-21 15:10:53
I think implicit in Phil's comments is the requirement/assumption that the new elements must be inserted by other existing elements of the same chare array. (what about the case of an existing element creating a second one, which creates a 3rd one? I don't think thats permissible within the same epoch.. i.e. the second and 3rd element cannot be part of the same epoch of reduction numbers. All the new elements must be created by elements the exist before the reduction is .. called.. [need more precise definition: ].
The task now is to document this and check in a program that shows its use (and tests it regularly).
