Project

General

Profile

Bug #1397

Document that array creation must occur on PE0

Added by Eric Mikida over 2 years ago. Updated over 2 years ago.

Status:
Merged
Priority:
Urgent
Assignee:
Category:
Documentation
Target version:
Start date:
02/05/2017
Due date:
% Done:

0%


Description

ckNew calls are restricted to PE0 since the 64-bit ID changes were integrated. Document this restriction in the array basics section of the manual. There's also a newly added API to call for array creation asynchronously, with the resulting array ID delivered through a callback. Document that in the intermediate/advanced section, and reference it from the earlier section.

insert.ci (359 Bytes) Jozsef Bakosi, 03/22/2017 10:33 AM

insert.h View (573 Bytes) Jozsef Bakosi, 03/22/2017 10:33 AM

insert.C View (1.02 KB) Jozsef Bakosi, 03/22/2017 10:34 AM

History

#1 Updated by Phil Miller over 2 years ago

  • Priority changed from Normal to High
  • Target version set to 6.8.0-beta1

This can't go into a release. Way too disruptive.

#2 Updated by Phil Miller over 2 years ago

  • Status changed from New to Feedback
  • Assignee set to Phil Miller

Waiting on info from bug reporter. I can't see what's causing problems in the code as it exists.

#3 Updated by Phil Miller over 2 years ago

  • Target version deleted (6.8.0-beta1)
  • Status changed from Feedback to Rejected
  • translation missing: en.field_closed_date set to 2017-02-21 12:18:12.593167

Unless we hear otherwise, this wasn't actually a problem that was occurring. Something else was conflated with this effect, probably.

#4 Updated by Jozsef Bakosi over 2 years ago

I finally got around to reproduce this problem with the attached minimal example. This mimics what I'm trying to do: from a driver chare, create an empty array and a group and from the group use insert() to add array entries. Note insert.C:34. If the driver chare is created on PE 0 all is well in both serial and parallel. However, change the Driver chare's PE to, e.g., 1, and run on two PEs and the following assert is generated:

[1] Assertion "CkMyPe() == 0" failed in file ckarray.C line 780.

I don't know if this is a behavior that would be incompatible with design/usability requirements, but this example does reproduce a behavior that was previously correct. Also, even if this is important for you guys to keep it this this way, i.e., array::ckNew() must always be called from PE 0, it is okay, because it appears that there is a simple fix: ensure that the driver is always created on PE 0.

#5 Updated by Phil Miller over 2 years ago

  • Subject changed from Dynamic array insertion fails when insert() is not called from PE 0 to Document that array creation must occur on PE0
  • Target version set to 6.8.0
  • Assignee changed from Phil Miller to PPL
  • Status changed from Rejected to New
  • Description updated (diff)

Indeed, this is intended behavior, that does limit usage that was previously allowed. As you note, there's a fairly easy workaround. We need to document this in the manual, as well as the asynchronous interface that lets the array creation call come from any PE, but returns the resulting ID through a callback

#6 Updated by Phil Miller over 2 years ago

  • Priority changed from High to Urgent

Setting priority higher because these are easy to fix things that act as paper-cuts to users

#7 Updated by Eric Bohm over 2 years ago

  • Assignee changed from PPL to Dong Hun Lee

#8 Updated by Sam White over 2 years ago

Here's the new API that can be used in the case of creation off PE 0: https://charm.cs.illinois.edu/gerrit/#/c/736/

#10 Updated by Dong Hun Lee over 2 years ago

  • Status changed from New to Resolved

#11 Updated by Sam White over 2 years ago

  • Status changed from Resolved to Implemented

This hasn't been merged yet, and once it is it should be marked 'merged' since there was something pushed into the repo

#12 Updated by Sam White over 2 years ago

  • Category set to Documentation
  • Status changed from Implemented to Merged

Also available in: Atom PDF