Charm++ parallel programming system

[Jozsef Bakosi <jbakosi AT gmail.com>]

Thank you, that makes it clear: any entry method that blocks (e.g., due to waiting for a future) should be declared [threaded].

On Wed, Jun 25, 2014 at 3:29 PM, Kale, Laxmikant V <kale AT illinois.edu> wrote:

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