Semaphore Issue

[Kirspel, Kevin]

BTW, is there any downside to enabling strict order mutex?  This will fix our issue but I'm not sure what other ramifications it may have.  We use a handful of semaphores (mostly for hardware protection) but I noticed that RTEMS creates a lot (mostly LBI*).

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

From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
Sent: Tuesday, August 14, 2012 5:47 PM
To: Kirspel, Kevin
Cc: rtems-users at rtems.org
Subject: Re: Semaphore Issue

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<mailto: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/519adbc1/attachment-0001.html>