Patch for "strict order mutex"

[xi yang]

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 .



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.

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"],

When building RTEMS , I find the "sync" and "gettimeofday"  tow functions
conflict with declarations in toolchain . (My toolchain is old ?)

Regards.


2007/12/23, xi yang <hiyangxi at gmail.com>:
> 2007/12/23, Chris Johns <chrisj at rtems.org>:
> > Joel Sherrill wrote:
> > > I apologize to everyone for not doing a better job before
> > > committing that patch. I ended up taking my wife to the
> > > hospital yesterday morning and I started committing to
> > > clean my tree at the end of the year.  I thought everything
> > > was OK but obviously I didn't do a full test run and I
> > > know I didn't try networking.
> Sorry,I missed the  initial_lock == CORE_MUTEX_LOCKED condition .
> That's my fault.
> I change the cpukit/configure.ac according
> __RTEMS_USE_TICKS_RATE_MONOTONIC_STATISTICS since I am not very
> familiar with
> the build system of RTEMS
> >
> > No harm done. This is CVS after all.
> Thanks for you find these bugs and changed them , I will do better next time .
> >
> > >
> > > The goal of this patch is good and desirable.  It just
> > > needs to work.  It should be optional because it does
> > > change behavior that has existed in RTEMS from the
> > > earliest public releases and because it does add some
> > > overhead.
> >
> > Does the change in behavior mean a better and more compliant RTEMS ?
> It could decrease the blocking time . It just allow releasing mutex in order so
> some older code which release mutex(inherited and celling) not in order can
> not works.
> >
> > If so then we need to turn this code on by default and allow a user to disable
> > it if they need time to fix their application.
> >
> > > I debated whether to leave it enabled or disabled by
> > > default and decided that enabled by default would
> > > get it tested.
> >
> > If this is an improvement to RTEMS I would like to see it on. I intend to do
> > some more testing when I have the time.
> I will write more tests for my patch.
> >
> > The issue was a bug in the configure part of the patch caused the code to be
> > compiled in and this exposed the bug. If the configure bug had not existed the
> > code could have sat with the bug for a long time.
> Sorry and thank you.
> >
> > Regards
> > Chris
> >
> Regards
>