Charm++ parallel programming system

[Phil Miller <mille121 AT illinois.edu>]

On Wed, Sep 19, 2012 at 12:55 PM, Geoff D. Hilyard
<gdhilyard AT regaldecision.com>
 wrote:
> Here is what I’m really trying to do ( Initialization step ):
>
> Read Gridpoint locations from a binary file
>
> [Repeat for a whole bunch of other items]
>
> In the previous case, the message being sent to the grid point is specific
> only to that grid point.  So, if I have 6k grid points, I will generate 6k
> unique messages.  Hence, I cannot call setVars on the first gridpoint, and
> it will call setVars on the second ( Like most of the examples in the
> examples folder ).
>
> “Note that in Charm++, an entry method runs until completion”
>
> I had assumed that things were asynchronous, and once the function was
> called, a message was sent.  I don’t have the [sync] keyword used for this
> function.

You understand correctly on this point: the messages you send are
dispatched immediately. However, Charm++ is not preemptive or
multiplexed - control of a PE stays with an entry method until it
returns or the thread it's running blocks.

> If I’m understanding you correctly, in my CCharmEntry::CCharmEntry(CkArgMsg*
> msg), I would read from file, send the messages, and exit.  At the end of
> the setVars function, I would call DoneWithSetupGridPoints on the mainProxy,
> which would have a counter of how many grid points need to call back.  Once
> all of them call back, I would call another function, in this case
> SetUpGridPointTopology.  This function would call SetupConnections on each
> Gridpoint ( in my case, since its an array, I can call gridPointArray.
> SetupConnections() and it will call them all, since order does not matter ).
> This function would call DoneWithGridPointSetupConnections on my mainProxy,
> which is the same as DoneWithSetupGridPoints.  Once all have reported back,
> I then go to the next step, etc., etc..
>
> Is this what I would have to do?  Is there a way, in the middle of an entry,
> to have the messages be dispatched?  Or is there a better way of
> initializing everything?  It seams the initialization would get very messy,
> and since I’m not the only one who will be working on this, I would like to
> make it as clean as possible.
>
> I’ve been thru the Hello examples, and have been poking around the other
> examples that are in the examples/charm++ directory.  I’ve also been thru
> the online manual a few times as well.  It almost looks like the SDAG stuff
> is what I really need, although I haven’t looked at it too indepth.

I believe Ehsan's concern is that after making all of the setup calls,
you have some sort of loop at the end of your Mainchare constructor
that runs indefinitely. What need to happen is the constructor must
return, so that the Charm++ scheduler regains control of that PE and
can process messages to be delivered locally. Those would include
messages to any chares (or chare array elements) created on PE 0, as
well as responses from other chares to the Mainchare indicating their
readiness or whatever.

Phil