Skip to Content.
Sympa Menu

charm - Re: [charm] Entry methods passing futures to each other -- should they all be declared threaded?

charm AT lists.cs.illinois.edu

Subject: Charm++ parallel programming system

List archive

Re: [charm] Entry methods passing futures to each other -- should they all be declared threaded?


Chronological Thread 
  • From: "Kale, Laxmikant V" <kale AT illinois.edu>
  • To: Jozsef Bakosi <jbakosi AT gmail.com>
  • Cc: "charm AT cs.uiuc.edu" <charm AT cs.uiuc.edu>
  • Subject: Re: [charm] Entry methods passing futures to each other -- should they all be declared threaded?
  • Date: Wed, 25 Jun 2014 21:29:35 +0000
  • Accept-language: en-US
  • List-archive: <http://lists.cs.uiuc.edu/pipermail/charm/>
  • List-id: CHARM parallel programming system <charm.cs.uiuc.edu>

Only the entry methods that *block* waiting for something (including, for
example, a future) need to be threaded. So, in you example, if I understand
it right, neither A nor B needs to be threaded. (Althoigh the name “run”
suggests that that method may have other blocking calls).

— Sanjay


On Jun 25, 2014, at 2:27 PM, Jozsef Bakosi
<jbakosi AT gmail.com>
wrote:

> Hi folks,
>
> I have classes A and B each with an entry method, e.g., in a .ci file:
>
> chare A {
> entry [threaded] void evaluate( CkFuture f );
> }
>
> chare B {
> entry [threaded] void run( CkFuture f );
> }
>
> Then B.run(), receiving a future, calls A.evaluate() via its proxy, passing
> its future on, which in turn creates a message and sends it via
> CkSendToFuture() to some function that's waiting for it. B.run() does not
> create a message, only A.evaluate() does eventually.
>
> The manual's Sec.12.2 advises that sync entry methods must be threaded (are
> threaded by default?), while Sec.12.3, discussing futures, declares
> fib::run() as threaded.
>
> Should the entry method that calls CkSendToFuture() be declared [threaded]
> or only the one that forwards a future or both?
>
> Does a [sync] method automatically assumes a [threaded] attribute as well?
>
> Would you recommend passing a future by value or it is also okay to pass it
> by reference? (I assume it needs to be communicated so it shouldn't matter.)
>
> Thanks,
> Jozsef
>
> _______________________________________________
> charm mailing list
> charm AT cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/charm






Archive powered by MHonArc 2.6.16.

Top of Page