Re: Complexity of protected objects

[dewar@gnat.com (Robert Dewar)]

Dale Stanbrough <dstanbro@bigpond.net.au> wrote in message news:<dstanbro-DD061F.15085703032002@mec2.bigpond.net.au>...
> Robert Dewar wrote:
> 
> > Remember that the key point about protected objects is 
> > the ceiling priority protocol, which ensures that 
> > higher priority tasks can still freely interrupt the 
> > lower priority tasks inside a PO with a lower CP.
> 
> Just to clarify - the sentence above seems to imply that 
> a low priority task inside a PO can be forceably removed 
> from the PO by a higher priority task that want the 
> -same- PO.

Of course not. It seems that you are not understanding
ceiling priority protocol at all here. The lower priority
task entering the PO immediately raises the priority to
the ceiling priority of that PO. The only interruption
allowed is by a higher priority task, i.e. whose priority
is, as in my message, higher priority than the ceiling
priority of the PO. But such a task is not allowed to
enter that PO (since you cannot call a PO if your priority
is higher than the ceiling priority).

This is absolutely fundamental to the operation of protected objects.
It also depends on run-till-blocked
semantics as required by Annex D, since you also cannot
time slice to an equal priority task if you are relying
on a lock-less implementation of PO's.

In fact most implementations do use locks and all these
considerations, including the worrying about PB operations
are irrelevant. 

> Ceiling priority protocal
> allows the high priority task to ensure it will be the 
> task to get access to the PO, and to ensure that low 
> priority  tasks "hurry up and get out of the way" when 
> working inside a PO.

Ah, I think I know your confusion, the above para makes
zero sense, but if you replace "Ceiling priority protocol"
by "Priority inheritance" it does make sense. I think you
are mixing up these two concepts.

> On the other hand if the higher priority task is 
> resources other than the PO used by the low priority 
> tasks, then I agree.

Well in that case you agree, because the ONLY time that
a task inside a PO can be preempted is by a task which
by definition cannot use the PO!

> Another name for POs/semaphores are "bottlenecks". If you
> want to increase the natural parallelism of a program, 
> you should make the code inside them as short as 
> possible.

Nope! That's much too crude a rule. The issue is contention
and minimizing context switching time.

The two things necessary for meeting strict performance
criteria in a hard real time application are

a) ensuring that high priority tasks that need immediate
control get immediate control (more properly, analyzing
carefully the maximum latency)

b) minimizing unnecessary context switching to decrease
overall system overhead

Keeping code in PO's short is neither necessary nor sufficient to
ensure that these goals are met.

Suppose you have three tasks in the system, two tasks
at low priority, and one at high priority.

The low priority tasks have no specific deadlines, but they
have a lot of computing to do, and it is important to minimize system
overhead. The high priority task must always be able to immediately
preempt.

Assume only one processor.

Assume we have a PO shared between the low priority tasks,
i.e. its ceiling priority is greater than or equal to that
of the low priority tasks, but lower than the high priority task.

In this situation the PO *can not* be a bottleneck, and there is
absolutely no loss from putting as much processing as you like in the
PO, providing you avoid blocking.

The bottom line in the design of real time systems is that
you have to control the entire behavior of the system, and
do a proper analysis. Trying to replace this with simplistic rules is
not a good idea. I always like the
results of RMA, because they are such a good antidote to
the myth of "obvious common sense" (it is so obvious that
more urgent tasks be given higher priority, right? :-)