Why vTaskPrioritySet doesn't set xEventListItem value according to uxPriority?

Kernel
8

I was thinking about that PR as well. And I found that doesn’t matter.

Because the following code was never changed since this post: two bugs in tasks.c.

listSET_LIST_ITEM_VALUE( &( pxTCB->xEventListItem ), ( ( TickType_t ) configMAX_PRIORITIES - ( TickType_t ) uxNewPriority ) );

The event item value just depends on uxNewPriority directly. No matter where the uxPriority or uxBasePriority came from. So, we could still get same problem if we use older code before the PR “Use the bigger priority whenever possible.#760”. The commit 60ef67c only changed the condition:

from

if( pxTCB->uxBasePriority == pxTCB->uxPriority )

to

if( ( pxTCB->uxBasePriority == pxTCB->uxPriority ) || ( uxNewPriority > pxTCB->uxPriority ) )

But that doesn’t matter at all. :sweat_smile:

If we use the code before the PR#760.

  • for the “imagined“ real life example (if we fix the blind spot of UART bus usage.)

The problem would still be there.

  • for the real test code

The problem would still be there. Because the critical part of code is the same.

The reason why we focus on the priority of a task may due to the priority is one of the most basic concept in kernel. In fact, if we set the event item value corresponding to uxPriority, it would be more stable. Because if

  1. The priority is not inherited, then the event item value should be changed depends on uxPriority.
  2. The priority is inherited, then the event item value should still be changed depends on uxPriority. It’s not a question about the vTaskPrioritySet should fail or not. The event item value would not be fiddled like the uxBasePriority. So it’s more stable and sensible.

Additional about the real life example:

If we use a timeout when TaskB waiting for the bus to BLE. Then TaskA’s event item would be reset to a correct value due to the disinheritance after timeout. And the deadlock would disappear. The cost is the communication error of BLE module and retry. In fact, this example is buggy. The taskA should use the same priority with TaskC, D if the TaskC, D has intense usage of SPI flash. If taskA use a priority lower than TaskC,D, it should expect a longer wait latency. So the only problem we could address from the example is when TaskA inherit higher priority from TaskB. Then TaskD should be unblocked after TaskA. But it wouldn’t work like this. Then TaskA may still wait for a long latency as usual. And TaskB would still have timeout error, due to the higher priority should expect shorter wait latency.

We may be used to set a timeout when taking a mutex. So it changes from a deadlock to some random error. That’s why I set an indeterminate wait timeout in test code to emphasize the problem. And it looks like an incomplete feature of vTaskPrioritySet.

1 Like