FreeRTOS + POSIX race condition in pthread_cond_timedwait()

roku-don wrote on Thursday, November 14, 2019:

Hello forum,

On 8/14/2019 I downloaded FreeRTOS+POSIX and from reading the code in FREERTOS_POSIX_pthead_cond.c I believed I had found a race condition in pthread_cond_timedwait().

On that day I filed the following bug with detailed explanation including code-snipptes:
https://sourceforge.net/p/freertos/bugs/197/

Today I hit the race condition, confirming it exists.

No one has yet been assigned owner for this bug.

I am REQUESTING ASSISTANCE OR AN UPDATE on this bug.

Thank you,
-Don Woodward

rtel wrote on Friday, November 15, 2019:

I Don - we are looking at this now and will provide an update shortly.

yuhzheng wrote on Friday, November 15, 2019:

Hi Don,

I could confirm the bug you reported on count underflow was a solid bug, and I do apologize for the delayed response to the forum post.

The bug had been fixed with the project re-uploaded to freertos.org lab. We did drop the communication on this change, which was also on us.

The most recent FreeRTOS+POSIX lab project could be downloaded here.
https://www.freertos.org/FreeRTOS-Labs/RTOS_labs_download.html
POSIX is located under ./FreeRTOS-Plus/Demo/FreeRTOS_Plus_POSIX_with_actor_Windows_Simulator/lib/FreeRTOS-Plus-POSIX.

Please note that:

  • The folder strutcture has been changed.
  • This version (zip name 190820-*) of POSIX depends on atomic.h. (we made some performance improvements.)

Also, to your specific concern about pthread_cond_timedwait():

  • This function does test- test-and-set logic on counter decrement. This addresses the underflow issue you’ve reported. Please check prvTestAndDecrement().
  • pthread_cond_timedwait() mutex release and count semaphore take in 190820-* is not “atomic” in our implementation. Please kindly note this is different from POSIX specification.
    http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_cond_timedwait.html.
    quote "These functions atomically release mutex and cause the calling thread to block on the condition variable cond; atomically here means “atomically with respect to access by another thread to the mutex and then the condition variable”

We are working on a better versioning scheme of freertos lab code. And hopefully next time the source control could state for itself for which version a user is consuming.

Regards,