Priority inherance issue

[Manuel Coutinho]

Ok
Have to said, it is getting complicated :)

>From what I realize, your method works almost perfectly with strict order.

But, for whom is doing the schedulability analysis, almost perfect will
complicate the math...too much (because have really to make sure that the
model is according to the implementation). I personally don't know any
published results with these types of implementation. Believe the only
existent schedulability results consider only the "perfect" implementation.
But, of course, I'm far from all-knowing and there can be some widely known
results about this.

Strict order will also restrict the developer somewhat.

So, what I would say that for soft/firm real-time, your solution, for me, is
perfect! Deterministic, almost perfect.
But for hard real-time, simple priority inherence should not be used at all.
Priority ceiling is much better.

Well, this is just my opinion...
Manuel Coutinho

> -----Original Message-----
> From: xi yang [mailto:hiyangxi at gmail.com]
> Sent: Wednesday, May 20, 2009 11:32 AM
> To: Manuel Coutinho
> Cc: Aitor Viana; Joel Sherrill; rtems-users at rtems.com
> Subject: Re: Priority inherance issue
> 
> Priority A >(higher)B>C>D
> T1: D obtains S2. Then S2.before = D
> T2: D obtains S1. Then S1.before =  D
> T3: C tries to obtains S1 and blocks. D's priority is improved to C,
> S1.before = D, S1.after=C
> T4: B tries to obtain S2 and blocks. D's priority is improved to B,
> S2.before = C, S2.after=B
> T5: A tries to obtain S1 and blocks, D's priority is improved to A,
> S1.before=B, S1.after = A
> T6: D releases S1. D's priority is decreased to B
> T7: A get and release S1
> T8: D releases S2. D's priority is decreased to C. But D's init priority
> is D.
> 
> Is it the problem you have said?
> 
> But, after D releases S2, kernel knows that D doest not hold any
> inherent mutex. So just set the priority of D back to the init
> priority.
> 

This was the problem, and I agree with the solution. Just wanted to have as
much description as possible, so that the implementation would be, as much
as possible, straightforward.

> I know, my method has problems like this:
> 
> Priority A >(higher)B>C>D
> T0: D obtains S3, Then S3.before = D
> T1: D obtains S2. Then S2.before = D
> T2: D obtains S1. Then S1.before =  D
> T3: C tries to obtains S1 and blocks. D's priority is improved to C,
> S1.before = D, S1.after=C
> T4: B tries to obtain S2 and blocks. D's priority is improved to B,
> S2.before = C, S2.after=B
> T5: A tries to obtain S1 and blocks, D's priority is improved to A,
> S1.before=B, S1.after = A
> T6: D releases S1. D's priority is decreased to B
> T7: A get and release S1
> T8: D releases S2. D's priority is decreased to C.
> 
> T9: Now, D have got S3 and there is no higher priority thread waiting
> on S3. But D's priority is C. Theoretically, this is a problem (D's
> priority should be D). But I think the priority of D is higher (May
> not equal) than any threads who wait for mutex held by D. Then, we can
> avoid priority invertion.
> 
> So, could we say that after release a inherent mutex, the priority of
> holder is not less than threads who wait for mutex held by the holder
> ?
> 
> This method is not perfect. But the cost of it is small.
> 
> Welcome more comments.
> 
> Regards