Hello, when the scheduler is suspended the FreeRTOS code in e.g. vTaskResume places the task in the ready list, and if the taskYield is required it (probably) relies on the vTaskSwitchContext that will just raise xMissedYield flag for the scheduler when it resumes. However xTaskResumFromISR uses a different approach and moves readied task to a separate xPendingReadyList. I don’t quite understand why the same code as in vTaskResume is not used here? IMHO it shouldn’t has problems with critical section (the comment in the vTaskResume code says : As we are in a critical section we can access the ready lists even if the scheduler is suspended.) since the xTaskResumFromISR is supposed to be called form an ISR with all apropriate context saved before?
When the scheduler is suspended interrupts can still execute so there has to be some mutual exclusion on the scheduler controlled data structures. The rule is that tasks can access the structures but interrupts cannot – so there is only one thing trying to access the structures at any one time. Interrupt cannot access the ready lists directly, so instead add readied tasks to the pending ready list from where they will be moved into their appropriate ready list when the scheduler is resumed. Regards.
But interrupts can happen also when the scheduler is not suspened. Why then the task is directly added to the ready queue? And I saw that all accesses to the scheduler structures are protected by the taskENTER/EXIT_CRITICAL in the task.c – so it should already guard against data corruptions by an ISR. Are you saying that only in suspended mode there is an unprotected access to the scheduler data structures in the code? Thank you again, Igor.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.