Skip to Content.
Sympa Menu

charm - Re: [charm] [ppl] [ppl-local] Q on Entry method

charm AT lists.cs.illinois.edu

Subject: Charm++ parallel programming system

List archive

Re: [charm] [ppl] [ppl-local] Q on Entry method


Chronological Thread 
  • From: Phil Miller <mille121 AT illinois.edu>
  • To: "Kale, Laxmikant V" <kale AT illinois.edu>
  • Cc: Charm Mailing List <charm AT cs.illinois.edu>, Nikhil Jain <nikhil.life AT gmail.com>
  • Subject: Re: [charm] [ppl] [ppl-local] Q on Entry method
  • Date: Sat, 29 Dec 2012 11:10:38 -0600
  • List-archive: <http://lists.cs.uiuc.edu/pipermail/charm/>
  • List-id: CHARM parallel programming system <charm.cs.uiuc.edu>

On Sat, Dec 29, 2012 at 2:48 AM, Kale, Laxmikant V
<kale AT illinois.edu>
wrote:
> Then, are you (the programmer) required to make sure only one of the sdag
> methods is active at a time? Otherwise, there is an ambiguity as to which
> of them will advance if both flows are waiting on (i.e.e expecting) the
> same entry method.

Yes, the programmer is responsible for making sure that there's no
ambiguity, or that it's not a problem. This could come by
1. limiting the control flow to just one of those methods executing at a time
2. using distinct tags in the two methods so that each matches unambiguously
3. writing the methods so that either one can process whichever
message it happens to get

AMR uses the first of these. CharmLU uses the first and the second -
pivoting can happen in a few different places, but it shares the same
methods.

> I'd prefer even a restrictive semantics, as long as it is unambiguous.

I'm not sure what you mean by this.




Archive powered by MHonArc 2.6.16.

Top of Page