In OpenComRTOS the equivalent of messages (implemented using Packet switching) inherit the priority of the generating Task. What criterium would you else us?
Only giving priorities to messages make little sense as they don't use a lot of the processing resources, whereas Tasks/Processes do.
What is scheduled is essentially CPU time and related to it units of bandwidth, when the message/packet goes over de wire/communication medium. For fairness reasons, packetisation also limits the blocking time when communicating (and it simplifies the communication buffering). Implementation wise, the use of packets also reduces all the copying that is needed (e.g.passing parameters) as locally the (RT)OS just passing points to it around. The application is hidden from this aspects.
Eric
From: Mailing List Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of Ruth Ivimey-Cook
Sent: Thursday, October 04, 2012 6:51 PM
To: occam-com@xxxxxxxxxx
Subject: Re: Programming prioritisation
Eric Verhulst (OLS) wrote:
In OpenComRTOS the equivalent of PRI PAR and PRI ALT come together. In my view, they can't be decoupled.
1. Tasks get a priority (at compile time). System wide attribute, so independently on which node they have been mapped. On each node, scheduling is in order of priority and preemptive.
This made me think: a long time ago, far far away... .no well anyway a long time ago someone suggested that the real thing that should have a priority attached to it was the communication itself: a message. Not the channel, or the task. The issue in ming, IIRC, was priority inversion. It has always struck me that this was a good model to go with, though I don't recall ever seeing it done or even investigated.
Regards
Ruth
--
Software Manager & Engineer
Tel: 01223 414180
Blog: http://www.ivimey.org/blog
LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/