Patch for "strict order mutex"

[Chris Johns]

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.

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

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

Should this be a runtime configuration with the extra overhead ?

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

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.

Regards
Chris