Peano

Searching...

No Matches

The string message looks like the other messages which I generate through DaStGen 2, but I actually wrote it myself manually to support dynamic string lengths. More...

#include <StringMessage.h>

Collaboration diagram for tarch::mpi::StringMessage:

[legend]

Public Member Functions
	StringMessage ()

	StringMessage (const std::string &value)

std::string	getData () const

void	setData (const std::string &value)

int	getSenderRank () const

std::string	toString () const

Static Public Member Functions
static void	sendAndPollDanglingMessages (const tarch::mpi::StringMessage &message, int destination, int tag)

static void	receiveAndPollDanglingMessages (tarch::mpi::StringMessage &message, int source, int tag)

static void	send (const tarch::mpi::StringMessage &buffer, int destination, int tag, MPI_Comm communicator)
	In DaStGen (the first version), I had a non-static version of the send as well as the receive.

static void	receive (tarch::mpi::StringMessage &buffer, int source, int tag, MPI_Comm communicator)

static void	send (const tarch::mpi::StringMessage &buffer, int destination, int tag, std::function< void()> startCommunicationFunctor, std::function< void()> waitFunctor, MPI_Comm communicator)
	Alternative to the other send() where I trigger a non-blocking send an then invoke the functor until the corresponding MPI_Test tells me that the message went through.

static void	receive (tarch::mpi::StringMessage &buffer, int source, int tag, std::function< void()> startCommunicationFunctor, std::function< void()> waitFunctor, MPI_Comm communicator)

static bool	isMessageInQueue (int tag, MPI_Comm communicator)
	In older DaStGen version, I tried to find out whether a particular message type is in the MPI queue.

Private Attributes
std::string	_data

int	_senderDestinationRank

Detailed Description

The string message looks like the other messages which I generate through DaStGen 2, but I actually wrote it myself manually to support dynamic string lengths.

Author: Tobias Weinzierl

Definition at line 34 of file StringMessage.h.

Constructor & Destructor Documentation

◆ StringMessage() [1/2]

tarch::mpi::StringMessage::StringMessage ( )

Definition at line 36 of file StringMessage.h.

◆ StringMessage() [2/2]

tarch::mpi::StringMessage::StringMessage ( const std::string & value )

Member Function Documentation

◆ getData()

std::string tarch::mpi::StringMessage::getData ( ) const

Definition at line 21 of file StringMessage.cpp.

Referenced by tarch::mpi::tests::StringTest::testSendReceive(), and toString().

Here is the caller graph for this function:

◆ getSenderRank()

int tarch::mpi::StringMessage::getSenderRank ( ) const

Returns: The rank of the sender of an object. It only make ssense to call this routine after you've invoked receive with MPI_ANY_SOURCE.

Definition at line 68 of file StringMessage.cpp.

◆ isMessageInQueue()

bool tarch::mpi::StringMessage::isMessageInQueue	(	int	tag,
		MPI_Comm	communicator )

static

In older DaStGen version, I tried to find out whether a particular message type is in the MPI queue.

That is, I looked whether a message on this tag does exist, and then I looked whether the memory footprint matches via count. I think this is invalid. MPI really looks only into the number of bytes, so you have to know which type drops in once there is a message on a tag.

Definition at line 135 of file StringMessage.cpp.

◆ receive() [1/2]

void tarch::mpi::StringMessage::receive	(	tarch::mpi::StringMessage &	buffer,
		int	source,
		int	tag,
		MPI_Comm	communicator )

static

Definition at line 78 of file StringMessage.cpp.

References _data, and _senderDestinationRank.

Referenced by receiveAndPollDanglingMessages(), and tarch::mpi::tests::StringTest::testSendReceive().

Here is the caller graph for this function:

◆ receive() [2/2]

void tarch::mpi::StringMessage::receive	(	tarch::mpi::StringMessage &	buffer,
		int	source,
		int	tag,
		std::function< void()>	startCommunicationFunctor,
		std::function< void()>	waitFunctor,
		MPI_Comm	communicator )

static

Definition at line 110 of file StringMessage.cpp.

References _data, and _senderDestinationRank.

◆ receiveAndPollDanglingMessages()

void tarch::mpi::StringMessage::receiveAndPollDanglingMessages	(	tarch::mpi::StringMessage &	message,
		int	source,
		int	tag )

static

Definition at line 49 of file StringMessage.cpp.

References tarch::mpi::Rank::getCommunicator(), tarch::mpi::Rank::getInstance(), tarch::services::ServiceRepository::getInstance(), receive(), tarch::services::ServiceRepository::receiveDanglingMessages(), tarch::mpi::Rank::setDeadlockTimeOutTimeStamp(), tarch::mpi::Rank::setDeadlockWarningTimeStamp(), tarch::mpi::Rank::triggerDeadlockTimeOut(), and tarch::mpi::Rank::writeTimeOutWarning().

Here is the call graph for this function:

◆ send() [1/2]

void tarch::mpi::StringMessage::send	(	const tarch::mpi::StringMessage &	buffer,
		int	destination,
		int	tag,
		MPI_Comm	communicator )

static

In DaStGen (the first version), I had a non-static version of the send as well as the receive.

However, this did not work with newer C++11 versions, as a member function using this as pointer usually doesn't see the vtable while the init sees the object from outside, i.e. including a vtable. So this routine now is basically an alias for a blocking MPI_Send.

Definition at line 73 of file StringMessage.cpp.

References _data.

Referenced by sendAndPollDanglingMessages(), and tarch::mpi::tests::StringTest::testSendReceive().

Here is the caller graph for this function:

◆ send() [2/2]

void tarch::mpi::StringMessage::send	(	const tarch::mpi::StringMessage &	buffer,
		int	destination,
		int	tag,
		std::function< void()>	startCommunicationFunctor,
		std::function< void()>	waitFunctor,
		MPI_Comm	communicator )

static

Alternative to the other send() where I trigger a non-blocking send an then invoke the functor until the corresponding MPI_Test tells me that the message went through.

In systems with heavy MPI usage, this can help to avoid deadlocks.

Definition at line 90 of file StringMessage.cpp.

References _data.