Patch for "strict order mutex"

[xi yang]

2007/12/24, Chris Johns <chrisj at rtems.org>:
> xi yang wrote:
> > 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
>
> This is the correct thing to do, how-ever it is a shell script and so you need
> to be careful with spaces. It seems I have left a problem in CVS which I will
> fix.
Yeah,also I have to read manuals of auto-tools .
>
> >> No harm done. This is CVS after all.
> > Thanks for you find these bugs and changed them , I will do better next time .
>
> I do hope you submit more patches that solve problems like this in RTEMS. It
> is most welcome. Well done for the patch.
>
> As for testing, I think we need to have all the examples and network demos
> run. This can be done with a simulator so hardware is not a issue.
Yeah,so the auto-test project of rtems is useful.
>
> >>> 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.
>
> Is the application code wrong and should it be fixed ?
If the application code dose not release mutex(inherited and ceiling)
in LIFO order.
>
> Should this be a runtime configuration with the extra overhead ?
May be add some value to the parameter of directive .
The main problem is that the application code should obtain and
release mutex in order.
Just like in textbook of Real-time OS.
>
> >> 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.
>
> Thanks.
>
> >> 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.
>
> I hope this came across as I intended. I do want the code in RTEMS and turned
> on. I do not like having to perform a special configuration to enable code.
> This is where bugs enter a system and hide.
My patch is an example ^-^, anyway , I have to test it carefully very much.
>
> We also need to fix the formatting of the code. This can be seen by looking at
> other score code. Here the spacing and line length are important. This code is
> very critical to RTEMS and I am more concerned about it than other places in
> RTEMS.
Ok, I try to fix them.
>
> Regards
> Chris
>