configUSE_PORT_OPTIMISED_TASK_SELECTION is 0 then task selection is performed in a generic way. There might be a racing condition on uxTopReadyPriority.
Please check this failed case:
Tick IRQ is a low priority IRQ.
When Tick IRQ finished this line “UBaseType_t uxTopPriority = uxTopReadyPriority;” , let’s assume uxTopReadyPriority and uxTopPriority is 5 now.
==> UBaseType_t uxTopPriority = uxTopReadyPriority;
/* Find the highest priority queue that contains ready tasks. /
while( listLIST_IS_EMPTY( &( pxReadyTasksLists[ uxTopPriority ] ) ) )
configASSERT( uxTopPriority );
/ listGET_OWNER_OF_NEXT_ENTRY indexes through the list, so the tasks of
* the same priority get an equal share of the processor time. /
listGET_OWNER_OF_NEXT_ENTRY( pxCurrentTCB, &( pxReadyTasksLists[ uxTopPriority ] ) );
uxTopReadyPriority = uxTopPriority;
} / taskSELECT_HIGHEST_PRIORITY_TASK */
A higher priority IRQ occurs, tick IRQ is switched out. The higher priority IRQ adds a ready task into the ready list and sets uxTopReadyPriority to this task’s priority, let’s assume it is 6.
The higher priority IRQ finished and tick IRQ contine it’s code. uxTopReadyPriority will be set to a value <= 5.
The task scheduler cannot call priority 6 task on next tick IRQ. That would cause some issues.