Priority inherance issue

[Manuel Coutinho]

Hi

Post 2 min ago ->
http://www.rtems.com/wiki/index.php/RTEMS_Algorithmic_Complexity#SuperCore

Please fell free to make any necessary changes -> talking mostly to Xi Yang.
Didn't want to talk about your implementation since you are obviously the
most indicated person to discuss it :).

Regards
Manuel Coutinho


> -----Original Message-----
> From: Chris Johns [mailto:chrisj at rtems.org]
> Sent: Wednesday, May 20, 2009 11:39 PM
> To: Manuel Coutinho
> Cc: 'xi yang'; rtems-users at rtems.com
> Subject: Re: Priority inherance issue
> 
> 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