Priority inherance issue

[Chris Johns]

Hi Manuel,

This discussion has been interesting and contains important information. 
Is it possible you both create a Wiki page with all this information ? I 
am sure others would be interested.

Regards
Chris

Manuel Coutinho wrote:
> 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
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users