Patch for "strict order mutex"

[Joel Sherrill]

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.

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.

I debated whether to leave it enabled or disabled by
default and decided that enabled by default would
get it tested. 

Sorry.

--joel


Chris Johns wrote:
> xi yang wrote:
>> cvs update -Pd
>> cvs diff -uN
>> Got the patch in attachment and the .tar of files of sp36 also in 
>> attachment.
>
> This patch has appeared in CVS on the head and does not work as is. 
> The networking stack caused the system to exit. This was due to 2 bugs 
> in the patch. The first caused it to be enabled all the time and the 
> second did not handle the case of a semaphore being created with a 
> count of 0 and therefore locked. This is what the networking stack 
> does. I have committed changes to fix these problems but I have not 
> tested them
>
> I have a few of issues with this patch.
>
> The first is not being enabled. How long will it sit not being used 
> and so maybe with bugs ?
>
> How well has it been tested ? The problems I have fixed are basic and 
> showed up with a simple network test application.
>
> In the couple of places I looked the code did not follow the coding 
> standard of the score. The __STRICT_ORDER_MUTEX__ should be 
> __RTEMS_STRICT_ORDER_MUTEX__. These need to be fixed.
>
> Could you please update to the latest code in CVS and fix the coding 
> standard issues plus report the testing done ? The test example could 
> do with some more tests (ie the locked semaphore test) and some real 
> world applications would also be good.
>
> We need to decide if this behavior is what we want and if so remove 
> the conditional compilation so the code is tested by everyone.
>
> The code needs to be review again.
>
> Regards
> Chris
>