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.