Tasks Priority

Hi I have a question concerning tasks priorities. In xTaskIncrementTick I see the following: ~~~ /* A task being unblocked cannot cause an immediate context switch if preemption is turned off. / #if ( configUSE_PREEMPTION == 1 ) { / Preemption is on, but a context switch should only be performed if the unblocked task has a priority that is equal to or higher than the currently executing task. / if( pxTCB->uxPriority >= pxCurrentTCB->uxPriority ) { xSwitchRequired = pdTRUE; } else { mtCOVERAGE_TEST_MARKER(); } } ~~~ We use preemption. So the task is ready due to the timing event that has expired, and it will be activated only if its priority is higher or *equal than the current task’s one. Question: why also if it is equal? We do not use configUSETIMESLICING, so actually the task should be prevented to become active. Is the task really activated or it will be anyway delayed until the completion of the curent task? If not activated, we could save a context switch interrupt, right? If it is activated anyway, then for me this is a bug. Thank you in advance.

Tasks Priority

To be honest I can’t remember why this was done – I do recall it was like that originally, changed to just “>”, then changed back. It will cause an immediate switch.

Tasks Priority

Thanks Richard do you agree that this is a bug if the task is switched in immedietely?

Tasks Priority

Moreover, I have some other cases here: vTaskPrioritySet: ~~~ if( pxTCB != pxCurrentTCB ) { /* The priority of a task other than the currently running task is being raised. Is the priority being raised above that of the running task? / if( uxNewPriority >= pxCurrentTCB->uxPriority ) { xYieldRequired = pdTRUE; ~~~ vTaskResume: ~~~ / The ready list can be accessed even if the scheduler is suspended because this is inside a critical section. */ ( void ) uxListRemove( &( pxTCB->xStateListItem ) ); prvAddTaskToReadyList( pxTCB );
                /* A higher priority task may have just been resumed. */
                if( pxTCB->uxPriority >= pxCurrentTCB->uxPriority )
                {
~~~ xTaskResumeFromISR: ~~~ if( uxSchedulerSuspended == ( UBaseType_t ) pdFALSE ) { /* Ready lists can be accessed so move the task from the suspended list to the ready list directly. */ if( pxTCB->uxPriority >= pxCurrentTCB->uxPriority ) { xYieldRequired = pdTRUE; } ~~~ xTaskResumeAll: ~~~ prvAddTaskToReadyList( pxTCB );
                /* If the moved task has a priority higher than the current
                task then a yield must be performed. */
                if( pxTCB->uxPriority >= pxCurrentTCB->uxPriority )
                {
                    xYieldPending = pdTRUE;
                }
~~~ I would like to point out that the management is not consistent, for instance in xTaskGenericNotify there is the following: ~~~
            if( pxTCB->uxPriority > pxCurrentTCB->uxPriority )
            {
                /* The notified task has a priority above the currently
                executing task so a yield is required. */
                taskYIELD_IF_USING_PREEMPTION();
            }
~~~ xTaskGenericNotifyFromISR ,vTaskNotifyGiveFromISR, xTaskAbortDelay have also only a” greater than”. I would say that a review of the tassks priority evaluation is urgently needed.