Patch for "strict order mutex"

[xi yang]

Here is the new patch . also the new sp36 test .
The test case is :

3)About this test program

  INIT
    *Create semaphore S0, which has RTEMS_INHERIT_PRIORITY
    *Create semaphore S1, which has RTEMS_PRIORITY_CEILING(1)
    *Create task T0 , whose priority is 4
    *Start T0
    *Delete himself

  T0
    *Create semaphore S2, which has RTEMS_PRIORITY_CEILING(1)
    	    	          and create it with LOCKED
    *Report pri of T0
    *Release S2
    *Report pri of T0
    *Obtain S0
    *Report pri of T0
    *Obtain S1
    *Report pri of T0
    *Release S0
    *Can not release S0 since releasing not in order
    *Release S1
    *Report pri of T0
    *Create semaphore S3, which has RTEMS_INHERIT_PRIORITY
    	    	          and create it with LOCKED

    *Report pri of T0
    *Create task T1 , whose priority is 1
    *Start T1
    *Priority of T0 is improved to 1
    *Release S3
    *Report pri of T0
    *Priority of T0 IS improved to 1
    *Release S0
    *Report pri of T0
    *Delete himself

  T1
    *Obtain S3
    *Release S3
    *Obtain S0
    *Release S0
    *Delete himself

Regards , welcome more tests .




2007/12/27, Joel Sherrill <joel.sherrill at oarcorp.com>:
> xi yang wrote:
> > 2007/12/24, Chris Johns <chrisj at rtems.org>:
> >
> >> xi yang wrote:
> >>
> >>> This afternoon I got the latest RTEMS from CVS then reviewed my patch
> >>> and find another problems in my patch also in your changes.
> >>>
> >>> 1)in coremutex.c .
> >>> Documents said :" If a binary semaphore is created with a count of
> >>> zero (0) to indicate that it has been allocated, then the task
> >>> creating the semaphore is considered the current holder of the
> >>> semaphore."
> >>> I missed this term so there is a bug in my patch . But I still find a
> >>> problem(maybe) that
> >>> in coremutex.c if initial_lock == CORE_MUTEX_LOCKED and the mutex is
> >>> inherit or celling
> >>> then we should add the mutex to the thread's lock mutex list . Also if
> >>> the mutex with
> >>> celling priority I think we should improve the Thread_Executing 's
> >>> priority to the celling
> >>> priority (right ?) just like what the
> >>> MACRO(_CORE_mutex_Seize_interrupt_trylock_body) in
> >>> coremutex.inl do (right?) . If you think it is right , I think we
> >>> should add the "check and improve the priority" codes to coremutex.c .
> >>>
> >>>
> >> I do not know. I will leave this for Joel to answer.
> >>
> Yes if you create it locked, it should act just like a create/lock
> combination.
>
> Chris, when this is done, we need to review how much code
> is inlined when locking a mutex.  Just as a matter of
> being sure too much is not done there.
> >
> >
> >>> 2)in sp36.
> >>> Sp36 is just used to test the strict_order_mutex , I added a return value for
> >>> rtems_semaphore_release directive , which is CORE_MUTEX_RELEASE_NOT_ORDER.
> >>> But this value just appear in code when __STRICT_ORDER_MUTEX__ is defined .
> >>> So I check whether __STRICT_ORDER_MUTEX__ is defied , if not , define
> >>> CORE_MUTEX_RELEASE_NOT_ORDER to a special value , in the begin of sp36,
> >>> test CORE_MUTEX_RELEASE_NOT_ORDER.
> >>>
> >> Great. Did you also add a test of a semaphore created locked ?
> >>
> > Yeah, I added it . I have to wait Joel answer the 1st question , then submit my
> > new patch. Thanks again.
> >
> This does need a test.  I would recommend actually at least 3
> test cases that are very close but are slightly different:
>
> For priority, priority inheritance, and priority ceiling
>   + task at priority 100
>       - create mutex 1 locked (if ceiling, pri = 90)
>       - check priority
>       - create mutex 2 locked (if ceiling, pri = 95)
>       - check priority
>       - create mutex 3 locked (if ceiling, pri = 80)
>       - check priority
>       - release  each and check priority
>
> By doing each protocol, you hit all cases (I think).
>
> Also do a case with ceiling where you up your
> priority both times but change the thread's priority
> in between the two creates.  Unlock in reverse
> order and check it.
>
> We also need a case where mutexes are not released
> in the right order.
>
> It doesn't have to be one executable.
> >>> 3)in cpukit/configure.ac
> >>> You changed it to
> >>> [test x"${ENABLE_STRICT_ORDER_MUTEX}"= x"1"],
> >>> But it should may be
> >>> [test x"${ENABLE_STRICT_ORDER_MUTEX}" = x"1"],
> >>>
> >> Yes this is the bug I did not see and fix.
> >>
> >>
> >>> When building RTEMS , I find the "sync" and "gettimeofday"  tow functions
> >>> conflict with declarations in toolchain . (My toolchain is old ?)
> >>>
> >> Yes. This is life on the bleeding edge of RTEMS and the tools. Thanks to Ralf
> >> all I need to do is issue a yum command to update.
> >>
> >> Regards
> >> Chris
> >>
> >>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strict_order_mutex.patch
Type: text/x-patch
Size: 11256 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20071228/ae0d7d83/attachment-0001.bin>