Charm++ parallel programming system

[Evghenii Gaburov <e-gaburov AT northwestern.edu>]

I seeking help with  completion detection module:

As described in documentation, I have the following constructor:

CProxy_CompletionDetector detector = CProxy_CompletionDetector::ckNew(); 

but at this the code fails to compile with the following error:

myMainChare.cpp: error: 'CProxy_CompletionDetector' was not declared in this 
scope.
myMainChare.cpp: error: expected ";" before 'detector'

I compile with  $charmc -module completion.

Is there something I am missing?

Thanks,
 Evghenii




On Sep 22, 2011, at 10:20 PM, Phil Miller wrote:

> There's actually a mechanism that Jonathan and I added recently to do
> localized completion detection, a sort of 'counting barrier'.
> Simdemics is actually using it, and it seems to be working well for
> them.
> The documentation for it can be found at
> http://charm.cs.illinois.edu/manuals/html/charm++/3_15.html#SECTION000315100000000000000
> That needs to be revised slightly, to indicate that production and
> consumption are both incremental processes that can potentially
> overlap. In the case posited, sending a request would correspond to a
> produce() call, while receiving a request and exporting data would
> correspond to a consume() call. When a given chare is done making
> requests, it calls done(), and eventually the library sees that all
> requests have been served.
> 
> Phil
> 
> On Thu, Sep 22, 2011 at 22:00, Kale, Laxmikant V 
> <kale AT illinois.edu>
>  wrote:
>> I think, in your context,  quiescence detection is the most elegant
>> solution. I am curious: Why do you not like it?
>> 
>> If you have multiple modules active at the time this exchange is
>> happening, and messaging form the other modules should continue across
>> this "import-export" activity, that would be one reason why QD is not a
>> good solution. But that¹s not the case for you.
>> 
>> May be the non-threaded version (CkStartQD with a callback) is better
>> suited?
>> 
>> Incidentally, how can you use MPI_Barrier in your MPI code? You wouldn't
>> know when to call it, since you don't know another process is not sending
>> a request your way next.
>> 
>> --
>> Laxmikant (Sanjay) Kale         http://charm.cs.uiuc.edu
>> <http://charm.cs.uiuc.edu/>
>> Professor, Computer Science     
>> kale AT illinois.edu
>> 201 N. Goodwin Avenue           Ph:  (217) 244-0094
>> Urbana, IL  61801-2302          FAX: (217) 265-6582
>> 
>> 
>> 
>> 
>> 
>> 
>> On 9/22/11 9:15 PM, "Evghenii Gaburov" 
>> <e-gaburov AT northwestern.edu>
>>  wrote:
>> 
>>> Dear All,
>>> 
>>> As a new user, who is porting his MPI code to Charm++, I have the
>>> following question:
>>> 
>>> I have a snippet of the code that requests data from remote chares, and
>>> these chares need to send data to the requesting chare. There is no way
>>> to know how many messages a give chare receives from remote chares with a
>>> request to export data. In other words, a given chare may need to export
>>> (different) data to many remote chares that request this, and this chare
>>> does not know how many remote chares request the data.
>>> 
>>> For logical consistency it is not possible to proceed with further
>>> computations unless all data requested is imported/exported. This leads
>>> me to issue with a global barrier, an equivalent if which,
>>> MPI_Barrier(MPI_COMM_WORLD), I use in my MPI code (there does not seem to
>>> be a way around such a global barrier, since this step established
>>> communication graph between MPI tasks, or for Charm++ between chares,
>>> which later use point-to-point communication).
>>> 
>>> Regretfully, I fail to find the most optimal way to issue such a barrier.
>>> Using CkCallbackResumeThread() won't work because the calling code (from
>>> MainChare that is a [threaded] entry) also sends messages to other remote
>>> chares with request to import/export data, and those themselves
>>> recursively send Msg to other remote chares to export data until close
>>> condition is satisified. (the depth of recursion is 2 or 3 calls to same
>>> function).
>>> 
>>> Now I use CkWaitQD() in the MainChare as a global synchronization point.
>>> I was wondering if there is a more elegant solution to issue a barrier so
>>> that all previous issued message completed before proceeding further.
>>> 
>>> Thanks!
>>> 
>>> Cheers,
>>> Evghenii
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> charm mailing list
>>> charm AT cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/charm
>> 
>> 
>> _______________________________________________
>> charm mailing list
>> charm AT cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/charm
>> 
>> _______________________________________________
>> ppl mailing list
>> ppl AT cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/ppl
>> 

--
Evghenii Gaburov, 
e-gaburov AT northwestern.edu