Software Integrity Ltd

I have simplified the prototype for send in order to make its use a little easier and also to improve the efficiency of the implementation. Here is the new prototype:

void send(MessagePtr& pMessage, const Event event);

The function no longer returns  a MessagePtr, and the concept of using a “system message”, in some circumstances, has gone. Instead, the MessagePtr is passed in by reference, so that it may or may not be invalidated, depending upon the success or failure of the operation.

The send function, as before, attempts to put the message on the task’s message queue. If this succeeds, pMessage is automatically invalidated when it is copied into the queue. If queueing fails, the pMessage argument remains valid and the status in the attached message is updated, as before, to identify the problem. The following code shows how the caller of send might check its outcome:

send (pMyMsg, EVENT_0);
if (!pMyMsg.valid())
{
    // Message has gone; no access any more.

    // Do any post-processing...
}
else
{
    // Message didn't go; we still have it attached to pMyMsg.
    // Optionally, find out why it didn't go.
    StatusCode status = pMyMsg->status();

    // Deal with the problem...
}

In the light of my coding experience yesterday evening, I now recommend that message pointers be passed to functions as C++ references unless there is good reason to do otherwise. Only the send function transfers a message to another context and only then, in general, need a transfer of ownership take place. Within a single context, things happen sequentially, so much of the overhead of copying message pointers, though small, can be avoided by using references.

The article on message reception will follow shortly.

Related posts:

1. SKC++: Sending Messages
2. SKC++: Receiving messages
3. SKC++: Message-Passing Classes
4. SKC++: Message-Passing Principles
5. SKC++: Message-Passing Uses