Priority inherance issue

[xi yang]

2009/5/21 Chris Johns <chrisj at rtems.org>:
> 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.
OK.
>
> 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.
Perfect implementation always needs O(n)  or O(logn)time in obtain or release.
>>
>> Strict order will also restrict the developer somewhat.
Yeah.
>>
>> 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.
Yeah.
The current implementation of _STRICT_ORDER_MUTEX is really simple and
crude. I have to refine it and try to submit a patch to import the
method we have discussed.
>>
>> Well, this is just my opinion...
>> Manuel Coutinho
Thanks for you have interested in _STRICT_ORDER_MUTEX_. Please excuse
my simple and crude implementation.
Welcome more comments .
Regards.
>>
>>> -----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
>