PRs #958 and #959 introduced a problem - when a task attempts to delete/suspend a task running on another core, there is a time window in which the task being deleted or suspended can take an action which puts it back on the ready list, thereby nullifying the delete/suspend operation.
The following example explains the problem:
/* TaskA, running on core0, deletes taskB running on core1. */
void vTaskA( void * params )
{
vTaskSuspend( task B );
...
}
void vTaskB( void * params )
{
/* Task B was at this point when it was deleted. */
/* Task B does an action (like calling xQueueReceive) which puts the
* task on ready/state/event list. The correct implementation of vTaskDelete
* must ensure that xQueueReceive is not be called after the task has been
* deleted. */
xQueueReceive( ... );
}
The root cause of the problem is that the task being deleted/suspended is evicted from the core after exiting the critical section. The task can put itself back on the ready list after we exit the critical section and before we evict it. This PR fixes the problem by evicting the task from within the critical section.
Test Steps
Before this PR, there are errors when running RP2040 standard SMP full demo.
FreeRTOS SMP on both cores:
Starting tests:
- Interrupt Queue
- Blocking Queue
- Block Time
- Counting Semaphore
- Generic Queue
- Recursive Mutex
- Semaphore
- Math
- Timer
- Queue Overwrite
- Event Group
- Interrupt Semaphore
- Task Notify
- Register
- Death
Iterations: 2; Errors now 00000001
Iterations: 3; Errors now 00001011
Iterations: 4; Errors now 000011d1
After the PR, there are no errors.
Checklist:
[x] I have tested my changes. No regression in existing tests. - Run RP2040 standard SMP full demo
Description
PRs #958 and #959 introduced a problem - when a task attempts to delete/suspend a task running on another core, there is a time window in which the task being deleted or suspended can take an action which puts it back on the ready list, thereby nullifying the delete/suspend operation.
The following example explains the problem:
The root cause of the problem is that the task being deleted/suspended is evicted from the core after exiting the critical section. The task can put itself back on the ready list after we exit the critical section and before we evict it. This PR fixes the problem by evicting the task from within the critical section.
Test Steps
Before this PR, there are errors when running RP2040 standard SMP full demo.
After the PR, there are no errors.
Checklist:
Related Issue
958, #959
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.