Charm++ parallel programming system

["Kale, Laxmikant V" <kale AT illinois.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