Charm++ parallel programming system

[Elliott Brossard <snowden AT cs.washington.edu>]

Thanks for all of your responses--I think I have the answers I needed now. I'll let you know if anything else comes up.

Thanks,
Elliott Brossard

On Thu, Nov 18, 2010 at 2:28 PM, Kale, Laxmikant V <kale AT cs.uiuc.edu> wrote:

Both David and Gengbin  have given relevant information. I will only add that calling “sleep” or other such blocking calls from Charm++ entry methods is not a reasonable thing to do, in most circumstances, because you are blocking the whole processor, not just the chare (i.e. threaded entry method) you are calling from. If the sleep was meant to just demonmstrate an issue, I understand. But otherwise, it should not be used.

 

A threaded entry method should suspend only by some mechanism that returns control to the charm scheduler. These mechanisms include: waiting for a sync method invocation, waiting for a future,  explicitly calling CThYield (which makes the thread available for resumption right away, but it sits behind other entities already in the queue, if its FIFO), or explicitly calling CThSuspend() (this  is done after storing the threaded in some local variable, so another method can CThAwaken() the thread). That’s probably more comprehensive answer than you needed but I thought I’d describe it. (depends on what you want to use Charm’s threads for).

 

 

 

 

 

From: charm-bounces AT cs.uiuc.edu [mailto:charm-bounces AT cs.uiuc.edu] On Behalf Of David Kunzman
Sent: Thursday, November 18, 2010 2:50 PM
To: Elliott Brossard
Cc: charm AT cs.uiuc.edu
Subject: Re: [charm] [ppl] Using [sync] entry methods

 

Hello Elliott,

   I'm not an expert on sync entry methods, but several people from PPL are at a conference at the moment, so I'll give it a shot.  I think there are two issues with the code that you sent.

   First, you should treat the constructor of the main chare object as being a bit special for other entry methods and even other constructors.  It is called while the runtime system is still in a startup phase (i.e. it's probably a bad idea to call a sync entry method from it, if it's even possible).

   Second, the way sync entry methods are intended to be called is by threaded entry methods.  My understanding of what should happen is basically this.  An threaded entry method calls a sync entry method, and in doing so, becomes suspended (i.e. the call blocks).  The sync entry method is executed.  The return value of the sync entry method is returned to the calling threaded entry method and the threaded entry method is reawakened to continue it's execution.

   Perhaps try the following.  In the main chare, call a second entry method from Main's constructor and make this new entry method threaded.  Once the main constructor returns, the Charm++ runtime should be fully initialized and the new entry method will be executed.  Then move the code that calls goToSleep() into the new threaded entry methods.  Hopefully that helps.

Thanks,
Dave K

On Thu, Nov 18, 2010 at 2:30 PM, Elliott Brossard <snowden AT cs.washington.edu> wrote:

Hello, both my advisor and I have been trying to use [sync] entry methods in Charm++ but without any luck. Here are the relevant bits of code:

From exclusive_chare.ci:
module exclusive_chare {
  array [1D] ExclusiveChare {
    entry ExclusiveChare();
    entry [sync] void goToSleep();
  };
};

From exclusive_chare.C:
void ExclusiveChare::goToSleep() {
    CkPrintf("Sleeping at index %d\n", thisIndex);

    for(int i = 0; i < 10; i ++)
        sleep(10);

    CkPrintf("Done sleeping at index %d\n", thisIndex);
}

From main.C:
Main::Main(CkArgMsg* msg) {
    int numChares = 10;
    mainProxy = thisProxy;

    exclusiveProxy = CProxy_ExclusiveChare::ckNew(numChares);
    for(int i = 0; i < 10; i ++) {
        CkPrintf("Calling sleep on chare %d\n", i);
        exclusiveProxy[i].goToSleep();
    }
}

However, when I compile and run the program, this is the output I see:
Charm++: scheduler running in netpoll mode.
Charm++> Running on 1 unique compute nodes (8-way SMP).
Charm++> Cpu topology info:
PE to node map: 0 0 0 0 0 0 0 0
Node to PE map:
Chip #0: 0 1 2 3 4 5 6 7
Charm++> cpu topology info is gathered in 0.010 seconds.
Calling sleep on chare 0

...after which there is no further output. It appears that Charm++ is blocking in a way that prevents the method from even being executed. Am I doing something wrong? If you could point me to a working example of [sync] entry methods that would be great.

Thank you,
Elliott Brossard
University of Washington
Department of Computer Science and Engineering

_______________________________________________
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