Re: Uneasy thoughts about priorities, priority inversion and protected objects

["J-P. Rosen" <rosen@adalog.fr>]

Le 27/02/2015 12:59, Jean François Martinez a écrit :
> Both Burns in his "Concurrent and Real Time Programming in Ada" and
> JP Rosen in his wikibook (in French) about software engineering
> "implement" (note the scare quotes) protected objects by giving a
> priority to the protected object that is inherited by a task when it
> runs in it. [...]
This is required only if you specify pragma Locking_Policy (Ceiling_Locking)

> Problem is: there are still priority inversions.  Let's consider the
> following scenario.  Task High is sleeping, Task Medium is waiting
> for I/O, Task Low is in protected Object.  Now I/O completes so Task
> Medium should get the processor but it doesn't because Low is in
> protected object with High's priority or more.  But nobody is waiting
> for the protected object so there is no hurry in getting Low out of
> it and no reason to delay Medium jsut because Low is in Protected
> Object.  
Scheduling is based on the active priority,  so when Low inherits a high
priority, it won't let Medium run (on a mono-processor).

> It seems to me a task on a protected object should have its priority
> raised only when a task with a higher priority queues behind it.  
This is called priority inheritance. It has the benefit of saving
useless priority changes, at the cost of a more complicated priority
change when required (a task has to change the priority of another task
while it is in the PO).

> Since I don't think for a second none of the smart people who
> designed Ada and none of the smart people who have read either the
> ARM, Burns'book or Rosen's wikibook haven't ever had a so obvious
> idea why is that we still are in the model I described on the first
> paragraph?  Because it is simpler to implement?  Because it is no big
> deal?  (You are supposed to leave the protected object _fast_).  Or
> is it because I missed someting?
When it comes to scheduling, for any algorithm, you can find an example
where it makes perfect sense, and an example where it would be
catastrophic. The "best" algorithm depends highly on your requirements
and your application profile.


-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr