NodeGroup Class Reference

#include <ckreduction.h>

Inheritance diagram for NodeGroup:

Collaboration diagram for NodeGroup:


Public Member Functions
	NodeGroup ()
	Locking is a big problem in the nodegroup code for smp.
	NodeGroup (CkMigrateMessage *m)
	~NodeGroup ()
const CkGroupID &	ckGetGroupID (void) const
CkGroupID	CkGetNodeGroupID (void) const
virtual bool	isNodeGroup ()
virtual void	pup (PUP::er &p)
	Pack/UnPack - tell the runtime how to serialize this class's data for migration, checkpoint, etc.
virtual void	flushStates ()
CK_REDUCTION_CONTRIBUTE_METHODS_DECL void	contributeWithCounter (CkReductionMsg *msg, int count)
Data Fields
CmiNodeLock	__nodelock
const int	thisIndex
Protected Attributes
contributorInfo	reductionInfo

Detailed Description

Definition at line 601 of file ckreduction.h.

Constructor & Destructor Documentation

NodeGroup::NodeGroup ( void )

Locking is a big problem in the nodegroup code for smp.

So a few assumptions have had to be made. There is one lock called lockEverything. It protects all the data structures of the nodegroup reduction mgr. I tried grabbing it separately for each datastructure, modifying it and then releasing it and then grabbing it again, for the next change. That doesn't really help because the interleaved execution of different threads makes the state of the reduction manager inconsistent.

1. Grab lockEverything before calling finishreduction or startReduction or doRecvMsg 2. lockEverything is grabbed only in entry methods reductionStarting or RecvMesg or addcontribution.nodegroup reduction manager . Most of it is similar to the guy above

Definition at line 2104 of file ckreduction.C.

References __nodelock, BGConverse::CkMyNode(), CmiCreateLock(), CkObjID::data, _ObjectID::group, Chare::mlogData, ChareMlogData::objID, _ObjectID::onPE, CkObjID::type, and TypeNodeGroup.

Here is the call graph for this function: