nopnop2002
commented
2 years ago This is not an issue for esp-idf.
There is no wait between xSemaphoreGive and xSemaphoreTake in task_b
static void task_b(void *arg) {
static const char* TAG = "B";
for (int i = 0; i < 500; i++) {
xSemaphoreTake(sem, portMAX_DELAY);
if (print) ESP_LOGI(TAG, "Taken");
vTaskDelay(pdMS_TO_TICKS(10));
esp_rom_delay_us(3546);
xSemaphoreGive(sem);
}
vTaskDelete(NULL);
}This is work.
static void task_b(void *arg) {
static const char* TAG = "B";
for (int i = 0; i < 500; i++) {
xSemaphoreTake(sem, portMAX_DELAY);
if (print) ESP_LOGI(TAG, "Taken");
esp_rom_delay_us(3546);
xSemaphoreGive(sem);
vTaskDelay(pdMS_TO_TICKS(10));
}
vTaskDelete(NULL);
}I (423) A: Take
I (423) A: Taken
I (423) A: Give
I (1423) A: Take
I (1423) A: Taken
I (1423) A: Give
I (2423) A: Take
I (2423) A: Taken
I (2423) A: Give
acf-bwl
AxelLin
Dazza0
wuyuanyi135
Zmmfly
SravanMaddukuri
Environment
git describe --tagsto find it): v4.3 v4.4.1 v5.0-dev-2443-g047903c612xtensa-esp32-elf-gcc --versionto find it): when building on v5.0-dev-2443-g047903c612: xtensa-esp32-elf-gcc.exe (crosstool-NG esp-2021r2-patch3) 8.4.0 when building on v4.4.1: xtensa-esp32-elf-gcc.exe (crosstool-NG esp-2021r2-patch3) 8.4.0 when building on v4.3: xtensa-esp32-elf-gcc.exe (crosstool-NG esp-2020r3) 8.4.0Problem Description
We have identified a problem with the FreeRTOS Semaphore API under esp-idf. When creating two tasks which each attempt to give and take a mutex repeatedly inside a loop, one task (task A) can become blocked permanently during a take operation. Meanwhile, the other task (task B) is able to give and take the mutex inside itself repeatedly for over five seconds, completely starving out the first task of access.
Procedure
The table below outlines the basic process of each of the two tasks in our sample code
Notes
Affected Versions
All three tested esp-idf versions were affected, but not under the same conditions. The matrix below indicates the conditions under which the two different log outputs were generated.
Expected Behavior
The intuitive expectation is that a "first-come-first-serve" system should exist for tasks of the same priority, with threads waiting the longest for the mutex being serviced first as the mutex becomes available.
Indeed, in FreeRTOS, semaphores are implemented as queues, which appear to offer this guarantee: Queues can have multiple readers, so it is possible for a single queue to have more than one task blocked on it waiting for data. [...] If the blocked tasks have equal priority, then the task that has been waiting for data the longest will be unblocked. Taken from: https://www.freertos.org/fr-content-src/uploads/2018/07/161204_Mastering_the_FreeRTOS_Real_Time_Kernel-A_Hands-On_Tutorial_Guide.pdf
It appears that this guarantee is being violated here: although A has been waiting to receive from the queue for many seconds and hundreds of queue sends and receives, xQueueSemaphoreTake in B continues to be serviced first before the same call in A.
In our example, we would expect Task A to be able to intermittently acquire the mutex during the test period.
Actual Behavior
After an initial period, Task A blocks forever while Task B takes and gives the semaphore to itself, starving task A entirely until the loop in Task B exits.
Possible Explanations
During our testing with v5.0-dev-2443-g047903c612, we determined that xQueueGenericSend in Task B was indeed identifying that another task of equal priority was waiting to acquire the mutex (or, receive from the queue), and correctly yielding control to the scheduler. The scheduler, however, chose to once again schedule task B to run again, as tasks A and B are both of the same priority. Task B then called xQueueSemaphoreTake, which quickly acquired the mutex / dequeued with no need to block. Task A does run at the next opportunity, when Task B calls vTaskDelay, but it is too late; the mutex has already been taken, and it must block again and wait for another opportunity.
As v4.3 is also affected when the priority of task A is set above the priority of task B, some other unidentified mechanism may be involved in that case.
Steps to reproduce
idf.py create-project..cfile.Code to reproduce this issue
Debug Logs
Note that A successfully takes the semaphore prior to B starting Once B starts A is not able to take the semaphore again until B's loop has ended and its task has exited. Then A is able to take the semaphore and complete its loop
Output 1 (Expected):
Output 2 (Actual):
Other items
good-log.txt bad-log.txt source.zip binaries.zip