Patch for "strict order mutex"

[Joel Sherrill]

xi yang wrote:
> 2007/12/24, Chris Johns <chrisj at rtems.org>:
>   
>> xi yang wrote:
>>     
>>> 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 .
>>>
>>>       
>> I do not know. I will leave this for Joel to answer.
>>     
Yes if you create it locked, it should act just like a create/lock
combination.

Chris, when this is done, we need to review how much code
is inlined when locking a mutex.  Just as a matter of
being sure too much is not done there.
>
>   
>>> 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.
>>>       
>> Great. Did you also add a test of a semaphore created locked ?
>>     
> Yeah, I added it . I have to wait Joel answer the 1st question , then submit my
> new patch. Thanks again.
>   
This does need a test.  I would recommend actually at least 3
test cases that are very close but are slightly different:

For priority, priority inheritance, and priority ceiling
  + task at priority 100
      - create mutex 1 locked (if ceiling, pri = 90)
      - check priority
      - create mutex 2 locked (if ceiling, pri = 95)
      - check priority
      - create mutex 3 locked (if ceiling, pri = 80)
      - check priority
      - release  each and check priority

By doing each protocol, you hit all cases (I think).

Also do a case with ceiling where you up your
priority both times but change the thread's priority
in between the two creates.  Unlock in reverse
order and check it.

We also need a case where mutexes are not released
in the right order.

It doesn't have to be one executable.
>>> 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"],
>>>       
>> Yes this is the bug I did not see and fix.
>>
>>     
>>> When building RTEMS , I find the "sync" and "gettimeofday"  tow functions
>>> conflict with declarations in toolchain . (My toolchain is old ?)
>>>       
>> Yes. This is life on the bleeding edge of RTEMS and the tools. Thanks to Ralf
>> all I need to do is issue a yum command to update.
>>
>> Regards
>> Chris
>>
>>