tacadia wrote on Tuesday, May 03, 2011:
This is a follow up on our issues presented in this thread.
I have done the patch as you’ve suggested and yes, it doesn’t hang anymore. When I did more tests, I found out that the issue in the original code that causes the uxTopReadyPriority to underflow will arise from the following sequence of execution:
1) Create Task1
2) Suspend Task1
3) Create Task2
4) Suspend Task2 <- (under flow occurs here)
When Task2 is created, uxCurrentNumberOfTasks has incremented to 2. However, with the old code, of:
/* The scheduler is not running, but the task that was pointed
to by pxCurrentTCB has just been suspended and pxCurrentTCB
must be adjusted to point to a different task. */
if( uxCurrentNumberOfTasks == ( unsigned portBASE_TYPE ) 1U )
/* No other tasks are defined, so set pxCurrentTCB back to
NULL so when the next task is created pxCurrentTCB will
be set to point to it no matter what its relative priority
pxCurrentTCB = NULL;
This causes the vTaskSwitchContext() to be invoked. When this happens, the while loop code:
/* Find the highest priority queue that contains ready tasks. */
while( listLIST_IS_EMPTY( &( pxReadyTasksLists[ uxTopReadyPriority ] ) ) )
configASSERT( uxTopReadyPriority );
Will cause the uxtopReadyPriority to underflow.
I see your point of now checking the number of suspended tasks with that of the uxCurrentNumberOfTasks. This only makes sense.
I thought I’d just document this here just in case someone comes by and wonder what all the underflow is about.
Thanks for the help once again Richard.