I was looking at the synchronization primitives in RIOT OS. I noticed that there is a mutex implementation, but I was unable to find a condition variable.
I am currently porting the TCP logic from the FreeBSD operating system to RIOT as part of the research work I am doing. I am implementing the “conn” API for TCP, and I need to be able to block the current thread until a packet is received, to implement some of the functions.
I read the IPC implementation (msg.c), which also has a blocking API, and saw that it interacts with the scheduler manually in order to block and resume threads. Before I did the same thing for the conn API (or perhaps implement/contribute my own condition variable), I wanted to ask whether there are condition variables for RIOT, in case I was just looking in the wrong place. If not, I want to learn if there is another structured way to block a thread until an event, that I should use instead.
Dear fellow TCP implementor,
The common way implement something like this in RIOT is Message
passing. Your thread simply blocks by calling msg_receive() until it
received a message from another thread. As soon as you receive a
Packet, send a message to the via msg_send() function to wake the
in its core RIOT only provides a small and efficient mutex implementation.
Condition variables are provided within the POSIX wrapper , specifically in the the pthread part .
To get an idea how use the provided condition variables you can have a look in our tests for it .
But as Simon stated you should consider if using the Message passing possibilities of RIOT could have the desired effect,
since using the POSIX condition variables in RIOT also comes with a certain overhead.
Thanks for the advice, Simon, Martin, and Kaspar!
For now, I’ll use a mutex together with thread_flags. Using message passing, as Simon suggested, would work for me as well; the reason I find thread_flags preferable is that I need to block application threads that call send() and receive(), that may already be using message passing.
If people don’t mind, and they think it would be useful, I’m also willing to contribute a lightweight condition variable to the core module. I think it could be implemented simply as a queue, just like the current mutex implementation.
The hole message passing avoidance is actually a pretty good point. I prefer message passing because I can handle the hole User Function call Timeout Handling with it as well. It would be interesting if a condition change could occur based on the expiration of a Timer.
Just my thoughts on that.