Home > Message-Passing, Projects, RTOS, SKC++ > SKC++: Message-Passing Uses

SKC++: Message-Passing Uses

Wednesday, November 4, 2009 Leave a comment Go to comments

Before jumping into the design of the message-passing classes, it is as well to consider how the facility might be used in applications.

I start with a common, nicely encapsulated but rather restricted kind of use…

Local Message-Passing

Local Message-Passing

In this slightly abused UML activity diagram we see that the message is created in someFunction, which is logically part of TaskB. This passes the message on to the activity function of TaskB. Note that this is done to cross the context boundary: TaskB::activity runs in context B, while TaskB::someFunction runs in context A, having been called, on this occasion, by the code of TaskA.

The designer of TaskB here has complete control of the structure, content and use of someMessage and none of this needs to be known outside of TaskB. Building a message can be error-prone: fields can be filled in incorrectly, of course, but a much more common error is to forget to fill some of them in at all. The person programming TaskB is less likely to make these mistakes than the programmer of TaskA, who is not particularly focused on messages “belonging” to TaskB and probably feels, with justification, that there is no need for such distractions. The potential errors – particularly the second – can be minimised by providing a purely functional interface to TaskB. A function cannot be called with an incorrect number of parameters or with incorrect parameter types, and code within the function can check for valid values, all before the corresponding message is built. All this, of course, is just the standard argument for hiding data.

An appropriate example

Suppose TaskB controls the RF section of a marine VHF radio. Its designer decides that the user interface functions should correspond one-for-one with the relevant controls on the panel, which are typically:

  • Channel selector knob
  • Channel 16 (emergency) override button
  • Power selector (low/high)

[For simplicity, I’m ignoring DSC – so consider the radio a “handheld”, to keep it legal!]

This is neat from TaskA‘s point of view but things are not straightforward inside TaskB. When a channel is chosen, we have to look up the corresponding transmitting and receiving frequencies, which may or may not be different. When the Channel 16 button is pressed, the power should be set to High unless and until specifically overridden. Conversely, when the channels either side of 16 are chosen, the power must be set to Low. There may be other things which I’ve forgotten, but this list will do for the present purpose.

Our designer decides that all of the above should be dealt within the user functions (by using a lookup table) and that each request should be delivered to the activity function using just one class of message with the following fields:

  • Transmitting frequency
  • Receiving frequency
  • Power level

This is undoubtedly tidier than having each user function send a different kind of message and making the activity function do the translation work as well as control the radio. More importantly for our purpose, though, it illustrates an appropriate use of local message-passing.

A problematic example

Suppose TaskA collects a large data block (maybe from a disk or a communications channel) and needs to pass it to TaskB for processing. Clearly, it would be crazy to pass this by value as an argument to a TaskB user function. But what happens if we pass a pointer (or reference) to the data, instead? All that data still has to be copied into the message which TaskB is responsible for creating, but it is to avoid just such copying that SKC++ has adopted the pass-by reference model for its messages! We could put just the data pointer into the message, but that brings back the ownership problem that SKC++ has already solved with its specialised auto_ptr (see the last article and the next one, when I’ve written it). There is an easy solution…

General Message-Passing

General Message-Passing

To solve the problem, we have had to take responsibility for the message structure, and the building of it, away from the receiving task. In this picture, TaskC creates the message and fills it up, passing it to TaskD::aFunction using the fancy, ownership-transferring pointer I keep talking about but haven’t yet properly described. It is then posted on to TaskD::activity in the usual way. In this situation, it is tempting to eliminate TaskD::aFunction altogether but, as we shall see, it is important to retain it to filter out unacceptable messages which might otherwise be posted in error to TaskD::activity.

In this approach, we have given up message-hiding in order to allow efficient and safe passing of messages around the system. Although we have taken responsibility for the message format away from the designer of TaskD, we have not simply handed the responsibility to the sending task, TaskC. That would have been a grave error of principle; I’ve seen it done and the consequences were ugly. Rather we now take the view that the message format is itself paramount and public. It is specified at a higher level than that of a task (maybe its design is dictated by the need to handle TCP/IP packets, or some such) and any tasks having to deal with it must be designed accordingly. We have generalised message passing so that a single message may be passed freely around any number of tasks which are able to deal with it. This is a common requirement in communication systems, particularly.

Conclusions

  • Local message-passing, because of its tight encapsulation, is best where it can do the job simply and efficiently.
  • General message-passing, as described, is necessary in many situations.
  • SKC++ message-passing techniques must support both.

Next Time

Message-passing classes

Advertisements
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: