Charm++ parallel programming system

[Akhil langer <akhilanger AT gmail.com>]

Charm does not guarantee message delivery order (charm uses UDP to deliver messages - on top of UDP charm has its built-in TCP like protocol but that is not sufficient to guarantee in-order delivery). 

After the message arrives at a PE, delivery to the user program can be ordered using one of the priority schemes. Please note the difference between http://charm.cs.illinois.edu/manuals/html/charm++/3_5.html 

and 
http://charm.cs.illinois.edu/manuals/html/charm++/3_8.html#SECTION00038300000000000000 (Messages are not guaranteed to be delivered in order). 


In your program, can the contribute call be moved to the remote chares recv method instead??

On Sat, Sep 24, 2011 at 8:59 PM, Evghenii Gaburov <e-gaburov AT northwestern.edu> wrote:

Hi All,

I have some misunderstanding upon the order in which the messages arrive. I read, that messages by default obey FIFO order

So, does the following code

"
void myClass::do_work()
{
 /* do some work first */
 for (int i = 0; i < nsend; i++)
  myClass[remoteIndex[i]].recv(results[i]);                       /* send data to remote chares */
 contribute(0, 0, CkReduction::concat, CkCallback(do_work_complete(), thisProxy));   /* barrier */
}

void myClass::recv(myResults remote_result) {  store_remote_result; }
void myClass::do_work_complete()            { process arrived remote_results; }
"

guarantees that myClass::recv(..) methods will be executed first (because they were called first),
and only afterwards a reduction part will call myClass::do_work_complete() (because it is called second).
This order is required to make sure that when do_work_complete is only invoked when *all* remote data has arrived.

Thanks!

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







_______________________________________________
charm mailing list
charm AT cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/charm