Home > Message-Passing, Projects, RTOS, SKC++ > SKC++: Sending Messages

SKC++: Sending Messages

Monday, November 16, 2009 Leave a comment Go to comments

This is a relatively short article, as the sending of messages from one task to another is straightforward. I decided to defer its counterpart, “Receiving Messages”, until next time because there are several things to consider there, making the subject worthy of an article of its own.

A while ago, I stated that messages can and should be generated locally (within the destination task object) if possible but that there were many occasions when it might be necessary or desirable to generate a message elsewhere and to pass it, ready-built, into that object. Either way, the message needs to be posted across the context boundary so that it can be queued and eventually processed by the destination task’s activity function.

Each message is associated with a specific event and is picked up by the receiving task using its wait function. I therefore considered overloading the post function to deal with messages, but decided instead to specify a new send function:

// New message-sending function.
MessagePtr send(MessagePtr pMessage, Event event);

// Post function prototype, for comparison.
void post(Event event);

Firstly, I decided that sending a message is different in concept from posting an event, even though event parameters are required in both cases. Secondly, post returns nothing whereas send returns a MessagePtr and I thought that it would be confusing to have overloaded post functions with  such different return semantics.

Before sending, a message will almost certainly have been handled using its type-specific MsgPtr<>. I could have made send a template function to allow the actual MsgPtr<> to be passed into the new context but that would have bloated the code. More importantly, it would have been pointless, as I hope will become clear next time, when I deal with receiving messages. So send uses the base class, MessagePtr, both as a parameter and as a return type.

The pMessage parameter is there, obviously, to pass the message to the send function. Note that the argument is passed by value; this is the point when the sender loses all access to the message, as the MessagePtr passed in is invalidated during the making of the necessary copy.

Each message to be sent is associated with an event. The waiting task can therefore, in principle, wait simultaneously at up to 16 different message queues. Furthermore, each message sent is effectively given a priority, namely that of the event associated with it.

The message might have originated elsewhere but the event to be associated with it should be decided within the realm of the destination task. This is one good reason (not the only one, as we shall see) for passing the message to a public function of the destination task and having it sent from there, rather than sending it directly from source to destination. To make the point, here again is one of the diagrams from “SKC++: Message-Passing Uses” :

General Message-Passing

Why does send return a message as well as sending one, and what kind of message does it return? Unlike posting an event, sending a message can fail. Messages are queued and queues can fill up, for example. Every message contains a status field which can be checked – where appropriate, as in this case – to see what happened.

If send succeeds, the message returned is a short system message (which need be considered no more than a message of the base class, Message). Its status field will indicate success.

If send fails, the message returned is the sender’s original message but with its status field altered to indicate the problem. It is important for recovery that the message be returned if not sent, as otherwise it would simply be lost: remember that the original pointer is invalidated on sending. There remains the small matter of “casting” the returned MessagePtr back to the original MsgPtr<> type, should that be needed. However, that is also an important topic for the next article, so I’ll defer it till then.

Categories: Message-Passing, Projects, RTOS, SKC++ Tags:
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: