
Home	Services	Products	Tutorials	Contact Us

Assigning Message Priorities

Some real-time systems may allow for message priorities, or at least the ability to force a message to the front of the message queue. This article illustrates some of the ways message priorities can be used. Typically message priorities are not used and messages enter the destination task's message queue in fifo order. Sometimes, however, more control over messages is required.

Emergency Messages Require High Priority

Consider taskA which has 5 messages backed up in its queue. taskB determines an emergency condition and sends taskA an emergency message. Without message priorities the emergency message would be placed behind the other 5 message already in taskA's message queue. However, if the message was sent with high priority, it would go straight to the front of the queue and be the next message that taskA receives.

Message Priorities and Server Tasks

Server tasks accept requests (messages) from other tasks to perform a function (printing for example). Consider taskA which previously requested that the server print a file. Even though the print is in progress, taskA wants to stop the print job. The problem is that after taskA made the print request, other requests to print were placed into the server's message queue. taskA can send a CANCEL_PRINT message, but it will be ineffective, because the message will not reach the server until the print job is done. The solution is for taskA to put a high priority on the cancel print message to force it ahead of all other messages in the queue.

Note that the server treats all requests the same, regardless of the priority of the task that sent the request. A high priority task can however put a high priority on the message and force his print request to the front of the queue so that it will be printed next.

A Note on How the Server Handles Requests

As a brief digression, note that if the server handles requests as shown below, the CANCEL_PRINT message may not be received in time; it will always be received after the current file is printed. If the current file being printed is the one to cancel, then the code below will not work.

void printServerTask(void)
{
	typeMsg * msg;

	while (TRUE) {
		msg = waitMsg(ANY_MSG);

		switch (msg->msgNum) {

		case PRINT_REQUEST:
			printFile(msg);
			break;

		case CANCEL_PRINT:
			cancelPrint(msg);
			break;
		}

		freeMsg(msg);
}

The proper way to code the server is shown below.

void printServerTask(void)
{
	typeMsg * msg;

	while (TRUE) {
		msg = waitMsg(PRINT_REQUEST);
		printFile(msg);
		freeMsg(msg);
}

void printFile(typeMsg * msg)
{
	typeMsg * cancelMsg;

	/* Get file name from msg, open file, etc. */

	while (notEof()) {
		printNextLineOfFile();
		cancelMsg  = rcvMsg(CANCEL_PRINT);
		if (cancelMsg != NULL) {
			freeMsg(cancelMsg);
			return;
		}
	}
}

printFile checks the message queue after printing each line for a CANCEL_PRINT message and if it finds one, printing is stopped and control is returned to the server. Note that rcvMsg is used instead of waitMsg since waitMsg would block if the CANCEL_PRINT message was not in the queue.

We welcome comments. Let us know what subjects you would like written up. Send comments to Mike@TicsRealtime.com