priority inherence bug?
Manuel
manuel.coutinho at edisoft.pt
Thu Dec 11 11:10:07 UTC 2008
Hi all
Sorry for the late reply (was out of office).
I did not read all the mails (yet), but I've done a simple search in RTEMS
for ENABLE_STRICT_ORDER_MUTEX and couldn't find any references (we are using
RTEMS 4.8.0).
I didn't fully understand the LIFO (or FIFO?) mechanism that you talked. But
it is an implementation issue that I did not yet address.
We understand that the priority of a task (with the priority inherence
mechanisms) is the "maximum of its own default priority and the priorities
of all the other tasks that are at that time depending on it" (taken from
"Real-Time Systems and Programming Languages", 3º edition, pag 488).
>From what I could tell, it seams that future versions of RTEMS will have
this behavior. We also believe this is the correct solution :).
Kind Regards
Manuel Coutinho
> -----Original Message-----
> From: xi yang [mailto:hiyangxi at gmail.com]
> Sent: Thursday, December 04, 2008 1:45 PM
> To: Joel Sherrill
> Cc: Manuel; rtems-users at rtems.com
> Subject: Re: priority inherence bug?
>
> On Wed, Dec 3, 2008 at 10:24 PM, Joel Sherrill
> <joel.sherrill at oarcorp.com> wrote:
> > xi yang wrote:
> >>
> >> On Wed, Dec 3, 2008 at 9:43 PM, Joel Sherrill
> <joel.sherrill at oarcorp.com>
> >> wrote:
> >>
> >>>
> >>> Thanks for the through answer.
> >>>
> >>> I would only add that the default and historic behaviour
> >>> Manuel describes is documented and was selected
> >>> since it was a simple solution which did not require
> >>> tracking. See the third paragraph here.
> >>>
> >>>
> >>> http://www.rtems.org/onlinedocs//doc-
> current/share/rtems/html/c_user/c_user00162.html
> >>>
> >>> We did not switch to strict order by default when it
> >>> was submitted because of two concerns. First as a change
> >>> to existing behaviour, it could have broken applications
> >>> in a subtle way. Second, it was new code and needed time.
> >>>
> >>
> >> Sorry, I didn't update the onlinedocs when I submitted the patch.
> >>
> >
> > It needs to be documented for sure. :(
> >>
> >> I think strict order may broke latency codes in two ways 1)It dosenot
> >> release mutex in LIFO order 2)It assumes that it still in a higher
> >> priority when it releases one of the mutex.
> >> For 1), Releasing mutex without LIFO order may leads to deadlock. So,
> >> breaking them is OK.
> >>
> >
> > I think enforcing that the release order is the opposite
> > of the acquire order is OK. Bad programming practice to
> > do otherwise since it can lead to a deadly embrace.
> >>
> >> For 2), maybe some programmers read the manual and do it like that :)
> >>
> >
> > I don't understand the issue for 2).
> For example. There is a thread T1 with priority A. T1 obtains the 1st
> mutex, then there is another thread try to obtain the mutex, T1's
> priority is improved to B. Then T1 obtains another 2ed mutex. After
> that, another higher priority thread try to obtain the 2ed mutex. T1's
> priority is improved to C. Then, T1 releases 2ed mutex and still think
> that its priority is still C. However, in "STRICT ORDER" environment,
> after T1 releases 2ed mutex, the priority of T1 decreases to B, wihch
> means a thread with a higher priority(>B) can preempt the T1 thread.
>
> >
> > --joel
> >>
> >> Regards
> >>
> >>>
> >>> It may be time to switch the default to using it and
> >>> getting time on the code so it is the default in 4.10.
> >>>
> >>> We can then consider killing the old behaviour in 4.11.
> >>>
> >>> It is important to be cautious when changing something like
> >>> this.
> >>>
> >>> --joel
> >>>
> >>> xi yang wrote:
> >>>
> >>>>
> >>>> On Wed, Dec 3, 2008 at 7:51 PM, Manuel <manuel.coutinho at edisoft.pt>
> >>>> wrote:
> >>>>
> >>>>
> >>>>>
> >>>>> Hi
> >>>>>
> >>>>> We are doing some tests to RTEMS and have stumbled in a possible bug
> >>>>> when
> >>>>> semaphores with priority inherence are used.
> >>>>>
> >>>>> Suppose a low priority task obtains two semaphores with priority
> >>>>> inherence.
> >>>>> After it obtains the critical region, other higher priority tasks
> also
> >>>>> try
> >>>>> to obtain the semaphores.
> >>>>> We have tested that the priority of the lower priority task is
> >>>>> correctly
> >>>>> raised to the priority of the highest priority task that tries to
> >>>>> obtain
> >>>>> the
> >>>>> semaphore. However, when the low priority task releases the first
> >>>>> semaphore,
> >>>>> its priority should decrease (because the second semaphore is only
> used
> >>>>> by
> >>>>> middle priority tasks). The priority of the lower priority task is
> only
> >>>>> restored to its original when it released the two semaphores.
> >>>>>
> >>>>>
> >>>>
> >>>> So, you want that if the task releases the mutex as LIFO order, just
> >>>> restore the priority of the task to the previous priority. You can
> >>>> enable the strict order function. In
> >>>> rtems-4.9.0/testsuites/sptests/sp36/sp36.doc, it write
> >>>> This is a simple test program to demonstrate strict order mutex.
> >>>>
> >>>> 1)What's strict order mutex ?
> >>>>
> >>>> In rtems,when a task release a priority_inheritance or
> >>>> priority ceiling semaphore,the kernel detect whether
> >>>> this task holds priority_inheritance or priority
> >>>> ceiling semaphore, if not, set the priority of task
> >>>> back to real priority of task.
> >>>> This method is right, but in theory, we would like
> >>>> to reset the priority after releasing the mutex if
> >>>> releasing it in LIFO order.Do it like this can decrease
> >>>> the blocking time of a higher priority task .
> >>>>
> >>>> 2)How to enable "strict order mutex " ?
> >>>>
> >>>> When configuring the rtems , add
> >>>> ENABLE_STRICT_ORDER_MUTEX=1
> >>>> to your configure parameter.
> >>>>
> >>>>
> >>>> 3)About this test program
> >>>>
> >>>> T0,T1,S0,S1
> >>>>
> >>>> T0,priority 4
> >>>> T1,priority 1
> >>>>
> >>>> S0,priority inheritance
> >>>> S1,priority ceiling,priority ceiling 1
> >>>>
> >>>> 1,T0 obtain S0 then obtain S1, priority of T0 should be improved to
> 1
> >>>> 2,T0 try to release S0, but not in strict order, return error code
> >>>> 3,T0 release S1,the priority of T0 back to 4
> >>>> 4,T1 try to obtain S0
> >>>> 5,T1 should be blocked and the priority of T0 should be improved to
> 1
> >>>> 6,T0 release S0
> >>>> 7,T1 obtain S0
> >>>> 8,OVER.
> >>>>
> >>>> Regards
> >>>>
> >>>>
> >>>>>
> >>>>> In our opinion, this is not the correct behavior of priority
> inherence
> >>>>> semaphores. We will try to correct this bug.
> >>>>>
> >>>>> Kind regards
> >>>>> Manuel Coutinho
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> rtems-users mailing list
> >>>>> rtems-users at rtems.com
> >>>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> rtems-users mailing list
> >>>> rtems-users at rtems.com
> >>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
> >>>>
> >>>>
> >>>
> >>> --
> >>> Joel Sherrill, Ph.D. Director of Research & Development
> >>> joel.sherrill at OARcorp.com On-Line Applications Research
> >>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> >>> Support Available (256) 722-9985
> >>>
> >>>
> >>>
> >>>
> >
> >
> > --
> > Joel Sherrill, Ph.D. Director of Research & Development
> > joel.sherrill at OARcorp.com On-Line Applications Research
> > Ask me about RTEMS: a free RTOS Huntsville AL 35805
> > Support Available (256) 722-9985
> >
> >
> >
More information about the users
mailing list