priority inherence bug?

Joel Sherrill joel.sherrill at OARcorp.com
Wed Dec 3 13:43:11 UTC 2008


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.

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





More information about the users mailing list