Semaphore Issue

Wed Aug 15 15:16:47 UTC 2012

On 15 August 2012 23:55, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
> On 08/14/2012 07:34 PM, Kirspel, Kevin wrote:
>
> 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*).
>
> I would run all the tests after enabling it.  :)
>
> I think it might use a little more memory for the additional
> bookkeeping. It also may result in your application getting an
> error code if you unlock in the wrong order.
>
> We need to discuss as a community if this should be turned on
> by default. Honestly, I was surprised we had forgotten to switch
> to this as default. :(

Joel,

Strict order mutex implementation has the limitation and is buggy.

1) You have to release mutex in LIFO order. For example, you lock
mutex m1,m2,m3....mn, you have to release it as mn,.....,m3,m2,m1.

2) The implementation is buggy :(  We discussed the problem at 2009.
Here is the link
http://www.rtems.com/ml/rtems-users/2009/may/msg00093.html

I think this is a good chance to fix the bug. I will try to submit the
patch next week.

Regards.

>
>
>
> 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        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
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>