Tasks Priority

davidefer wrote on Thursday, August 16, 2018:

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 configUSE_TIME_SLICING, 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.

rtel wrote on Thursday, August 16, 2018:

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.

davidefer wrote on Friday, August 17, 2018:

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

davidefer wrote on Friday, August 17, 2018:

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.