Semaphore Issue

Joel Sherrill joel.sherrill at OARcorp.com
Wed Aug 15 13:55:53 UTC 2012


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. :(
>
> 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
>   


-- 
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/20120815/771732c0/attachment-0001.html>


More information about the users mailing list