Minor bug in 4.3.1 xQueueSend()/XQueueRecieve

dansear wrote on Friday, July 27, 2007:

In 4.3.1:

Small issue in xQueueSend() and xQueueReceive() in queue.c.

Near the end, where it has the code:

        if( xTicksToWait > 0 )
        {
                if( xTaskCheckForTimeOut( &xTimeOut, &xTicksToWait ) == pdFALSE )
                {
                        xReturn = queueERRONEOUS_UNBLOCK;
                }
        }

I recommend:

        #if ( INCLUDE_vTaskSuspend == 1 )
        if(( xTicksToWait > 0 ) && ( xTicksToWait != portMAX_DELAY ))
        #else
        if( xTicksToWait > 0 )
        #endif
        {
                if( xTaskCheckForTimeOut( &xTimeOut, &xTicksToWait ) == pdFALSE )
                {
                        xReturn = queueERRONEOUS_UNBLOCK;
                }
        }

xTicksToWait is set portMAX_DELAY for indefinite waits, but without
the above change, it will be decremented.  This slightly effects
later code, which processes threads differently depending on if
their wait time is portMAX_DELAY or not.

Dan Searles

rtel wrote on Friday, July 27, 2007:

Hmm.  I think you have a good point.  This part of the code came about from the SafeRTOS validation process - but in SafeRTOS there is no method of waiting indefinitely so the problem does not exist.  The error was made when integrating this into the FreeRTOS.org code.

I think the fix would be better in xTaskCheckForTimeOut() to prevent it being duplicated in xQueueSend() and xQueueReceive().  Also these two functions are alread the most complex in the system, so best not to add code to them if possible.

Thank you for your contribution.

Regards.