Charm++ parallel programming system

[Phil Miller <mille121 AT illinois.edu>]

2011/9/22 Kale, Laxmikant V 
<kale AT illinois.edu>:
> If you have a request-rsponse scenario (1 response for 1 reuest), and you
> know when you are done making your last request, then you can use a
> barrier; I.e. A contribute call, with CkReduction::nop.

A reduction can tell you when all of the requests have been sent, and
how many of them there were, but it doesn't tell when they're all
received and dealt with, nor does it tell any particular recipient how
many requests are coming its way.

> I wasn't sure what you meant by "recursive". If a request can trigger
> another request, then, of course, you don't know when you are done making
> requests by yourself; QD is useful in this context. And if you know when
> you are done sending messages, but you don't have "responses" then you can
> use the module Phil mentioned.

Recursive requests are an interesting case, that came up in the recent
AMR work here, too. If a module can't tell when it will make no new
requests, then yeah, my completion detector can't help, and QD is the
way to go. If we can come up with an explicit way to address that
(I've got some ideas bouncing around), it may be useful in a number of
different cases, since it's composable where QD isn't.

However, responses are not an impediment to using explicit detection
instead of QD. The target of the response message would simply be the
one to make a consume() call, rather than the target of the request.