priority inherence bug?

[xi yang]

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.
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.
For 2), maybe some programmers read the manual and do it like that :)
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
>
>
>