priority inherence bug?

[Joel Sherrill]

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).

--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