Spurious wakeups on semaphores

[dns13]

In your ReadWriteLock you should check the return values of your xSemaphoreTake() calls to be prone against spurious wakeups. For example if you call vTaskAbortDelay() to wake up a sleeping task from another, it will also cancel your waits on the semaphore. Unfortunately that behaviour is not really documented, but I've ran into it - took me a while.

I do it like so

while (xSemaphoreTake(sem, portMAX_DELAY) != pdTRUE) {}

[dns13]

Seems to be fixed with FreeRTOS v11.0.0:

• Prevent tasks waiting for a notification from being resumed by calls to vTaskResume or vTaskResumeFromISR. We thank @Moral-Hao for their contribution.

[Moral-Hao]

Hi, @dns13 , I don't think the change I made could fix the problem you described. Before my change, a task waiting for a notification with portMAX_DELAY may be identified as suspended, and this task could be woke up by vTaskResume. After my change, this task could not be woke up by vTaskResume. A task waiting for something(semaphore/event/notify) with portMAX_DELAY still could be woke up by xTaskAbortDelay.