Semaphore Issue

[Joel Sherrill]

On 08/14/2012 04:15 PM, Kirspel, Kevin wrote:
>
> I have a situation with semaphores that I thought someone may have a 
> quick explanation for.  The scenario consists of 2 semaphore/mutexes 
> and priority inheritance.  The first semaphore is created by the 
> application (S1) and is of type: RTEMS_BINARY_SEMAPHORE | 
> RTEMS_PRIORITY | RTEMS_INHERIT_PRIORITY.  The second (S2) is the 
> allocator lock mutex that is used by malloc().  My scenario is as follows.
>

> Task 1 has priority 36.  Task 2 has priority 34.
>
> 1.Task 1 obtains S1.
>
> 2.Task 1 obtains S2
>
> 3.Task 2 preempts Task 1.
>
> 4.Task 2 tries to obtain S2 but can’t get it.  Task 1 priority is 
> changed to 34.
>
> 5.Task 1 begins running again.  Task 1 releases S2.  Task 1 priority 
> is not changed back to 36 and continues to run.
>
> 6.Task 1 continues operating for 3 more seconds.
>
> 7.Task 1 releases S1.  Task 1 priority is now changed back to 36.
>
> 8.Task 2 now preempts Task 1 and begins operating again.
>
What RTEMS version is this?

This sounds like the priority inheritance release algorithm described here:

http://rtems.org/onlinedocs/doc-current/share/rtems/html/c_user/c_user_208.html#Semaphore-Manager-Priority-Inheritance

Priority inherited is not lowered until ALL mutexes are released.

There is an optional algorithm (don't recall if it is turned on by 
default) that
is guarded by the __RTEMS_STRICT_ORDER_MUTEX__ conditional.
configure with ENABLE_STRICT_ORDER_MUTEX=1 on the command line to
try this algorithm which should properly step down as each mutex is 
released.

> Task 1 is the main user of Semaphore S1.  During normal operation no 
> other task will try to obtain it.  It is there to protect against some 
> custom shell commands that may access the same data.  Semaphore S2 is 
> widely used since it protects memory allocation.  If 
> obtaining/releasing S1 is removed from the scenario above then 
> everything works OK.
>
> 1.Task 1 obtains S2
>
> 2.Task 2 preempts Task 1.
>
> 3.Task 2 tries to obtain S2 but can’t get it.  Task 1 priority is 
> changed to 34.
>
> 4.Task 1 begins running again.  Task 1 releases S2.  Task 1 priority 
> is now changed back to 36.
>
> 5.Task 2 now preempts Task 1 and begins operating again.
>
> 6.Task 2 enters wait condition.
>
> 7.Task 1 continues operating for 3 more seconds and then enters wait 
> condition.
>
> I am going to try and duplicate this scenario using a small test 
> program but I wanted to see if anyone had any ideas of what may be 
> causing the issue.  I have a mixed RTEMS source base between versions 
> 4.10 and 4.11.   I started with 4.10 and upgraded just enough to get 
> USB support.
>
Any chance you want to pitch in and help resolve some issues on the 
TCP/IP side?
We are now up to the IPV4 loopback test and would LOVE to have help. :)
>
> Kevin Kirspel
>
> Senior Research Engineer
>
> Opti Medical
>
> 235 Hembree Park Drive
>
> Roswell GA 30076
>
> Tel: (770)-510-4444 ext. 81642
>
> Direct: (770)-688-1642
>
> Fax: (770)-510-4445
>


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20120814/31fc1219/attachment-0001.html>