Patch for "strict order mutex"

[xi yang]

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