Patch for "strict order mutex"

[xi yang]

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.

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