[PATCH 6/6] Thread Queue: Merge discipline subroutines into main methods

[Joel Sherrill]

On September 19, 2014 7:28:36 AM CDT, Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
>On 08/07/14 22:52, Joel Sherrill wrote:
>> There was a lot of duplication between the discipline subroutines.
>> With the transition to RBTrees for priority discipline, there were
>> only a few lines of source code manipulating the data structure
>> for FIFO and priority. Thus is made sense to fold these back
>> into the main methods.
>>
>> As part of doing this all of the tests for discipline were changed
>> to be in the same order.
>[...]
>> diff --git a/cpukit/score/src/threadqdequeue.c
>b/cpukit/score/src/threadqdequeue.c
>> index 93d5c07..3b55e52 100644
>> --- a/cpukit/score/src/threadqdequeue.c
>> +++ b/cpukit/score/src/threadqdequeue.c
>[...]
>> +  /*
>> +   * We did not find a thread to unblock.
>> +   */
>> +  if ( !the_thread ) {
>> +    sync_state = the_thread_queue->sync_state;
>> +    if ( (sync_state == THREAD_BLOCKING_OPERATION_TIMEOUT) ||
>> +         (sync_state == THREAD_BLOCKING_OPERATION_NOTHING_HAPPENED)
>) {
>> +      the_thread_queue->sync_state =
>THREAD_BLOCKING_OPERATION_SATISFIED;
>> +      the_thread = _Thread_Executing;
>>       }
>> -  _ISR_Enable( level );
>> +    _ISR_Enable( level );
>> +    return NULL;
>> +  }
>
>This introduced a serious bug and its pretty sad that the test suite
>didn't 
>find it.  This is one of the core routines and we had no proper test
>case for it.
>
>In case we set the_thread_queue->sync_state = 
>THREAD_BLOCKING_OPERATION_SATISFIED we must not return NULL.

:( other than adding debug asserts, any ideas on how to test this? It is an internal state that the tests are not supposed to have visibility on.

It should be possible to add a wrapper to thread queue operations when debug is enabled which checked the various conditions.

At least that would have caught it.

--joel