doc: array-map creation ordering and creation dependence for arrays - #3931
Open
lvkale wants to merge 1 commit into
Open
doc: array-map creation ordering and creation dependence for arrays#3931lvkale wants to merge 1 commit into
lvkale wants to merge 1 commit into
Conversation
The Initial Placement section showed ckNew of a map group immediately followed by ckNew of the array using it, with no ordering discussion. That idiom is safe only during program initialization (mainchare constructors), where creations are installed on every PE in creation order before the scheduler runs other messages. Created later in the run, the array creation races the map group creation on remote PEs and aborts in the array constructor with 'Local branch of array map is NULL!' (observed at 32 processes in a production application; the internal dependence chain covers plain setMap but not bindTo combined with a newly created map). Documents the fix: declare the map as a creation dependence of the array via CkEntryOptions::setGroupDepID, cross-referencing the existing group-on-group dependence section. Also corrects the CkArrayMap base class in the manual (IrrGroup, not Group) and notes the consequence that map classes cannot contribute to reductions.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Initial Placement Using Map Objects section shows ckNew of a map group immediately followed by ckNew of the array that uses it, with no discussion of ordering. That idiom is safe only during program initialization (mainchare constructors), where creations are installed on every PE in creation order before the scheduler executes other messages. Created later in the run, the array creation races the map-group creation on remote PEs and aborts in the array constructor with "ERROR! Local branch of array map is NULL!". We hit this at 32 processes in a production application (paratreet2): the internal dependence chain in CkCreateArray covers the plain setMap case (locCache depends on the map), but an array created with both bindTo and a newly created map reuses the bound-to array's location manager, skips that chain, and is unprotected.
This PR documents:
A possible code follow-up, not part of this PR: CkCreateArray could declare the map dependence itself on the bindTo path.
🤖 Generated with Claude Code