Skip to Content.
Sympa Menu

charm - Re: [charm] barrier without reduction

charm AT lists.cs.illinois.edu

Subject: Charm++ parallel programming system

List archive

Re: [charm] barrier without reduction


Chronological Thread 
  • From: Robert Steinke <rsteinke AT uwyo.edu>
  • To: Phil Miller <mille121 AT illinois.edu>
  • Cc: Charm Mailing List <charm AT cs.illinois.edu>
  • Subject: Re: [charm] barrier without reduction
  • Date: Tue, 12 Aug 2014 11:16:58 -0600
  • List-archive: <http://lists.cs.uiuc.edu/pipermail/charm/>
  • List-id: CHARM parallel programming system <charm.cs.uiuc.edu>

Thanks.  This is helpful.  At least it keeps all of the code within the chare group.

On 08/12/2014 11:05 AM, Phil Miller wrote:
Hi Bob,

What you're doing now definitely has at least a somewhat simpler _expression_ in Charm++. Rather than directing the reduction to a mainchare, and then broadcasting to the group, a reduction can be targeted to do the broadcast directly. The code for the callback declaration would look like

CkCallback cb(CkReductionTarget(MyGroupClass, barrierDone), thisgroup);

where your .ci file contains a definition like

group MyGroupClass {
    . . .
    entry [reductiontarget] void barrierDone();
};

Then each group member entering the barrier would just call

contribute(cb);


If you were to sequence all of this with SDAG code, the overall ci file for this aspect of the group would look like

group MyGroupClass {
    . . . // other entry method definitions
    entry [reductiontarget] void barrierDone();
    entry void doWrites() {
         serial {
            defineFile1();
            contribute(cb);
         }
         when barrierDone() serial {
            writeFile1();
            contribute(cb);
         }
         when barrierDone() serial {
            closeFile1();
            defineFile2();
            contribute(cb);
         }
         when barrierDone() serial {
            writeFile2();
            contribute(cb);
         }
         when barrierDone() serial {
            closeFile2();
            defineFile3();
            contribute(cb);
         }
         when barrierDone() serial {
            writeFile3();
            contribute(cb);
         }
         when barrierDone() serial {
            closeFile3();
         }
    };
};

If the definition, writing, and closing can be parameterized over the various files, then this could be abstracted to

group MyGroupClass {
    . . . // other entry method definitions
    entry [reductiontarget] void barrierDone();
    entry void doWriteX(FileDetails X, CkCallback doneWritingX) {
         serial {
            defineFile(X);
            contribute(cb);
         }
         when barrierDone() serial {
            writeFile(X);
            contribute(cb);
         }
         when barrierDone() serial {
            closeFile(X);
            contribute(doneWritingX);
         }
    };
};



On Tue, Aug 12, 2014 at 11:43 AM, Robert Steinke <rsteinke AT uwyo.edu> wrote:
Is there a way in Charm++ to do a barrier without doing a reduction?

I have a situation where I need a chare group to do six barriers through a sequence of code.  Having them do a reduction to the main chare and then have the main chare send a message to proceed is bloating the code.  I don't need to do a reduction to produce a value.  I just need a barrier.  It would be nice if I could just put a barrier statement in the charm group code.

I suppose one solution would be to call MPI_Barrier directly, but I don't like that solution.  First of all, is it safe to do that from within my Charm++ code?  Will it always be safe in future versions of Charm++?  It seems like a dangerous use of undocumented functionality.  Also, the code would not be portable to Charm++ installs that were not compiled to use MPI.

For anyone who is curious why I need six barriers, this group is using a parallel library to write NetCDF files.  Every member must perform define actions where they specify what variables are in the file.  Then they all perform data actions where they write values to those variables.  Then they all must close the file.  The define actions of all group members must be done before any group member performs a data action, and the data actions of all group members must be done before any group member closes the file.  I need two barriers per file and they are doing this for three files so I need six barriers.  This is an infrequent operation so speed is not much of an issue, just code bloat.

Bob Steinke

_______________________________________________
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