[riot-devel] Message queue that is not bound to a reveiving thread

Juan Ignacio Carrano j.carrano at fu-berlin.de
Thu Jul 12 12:31:28 CEST 2018

Hi Gunar,

A semaphore is a common way of implementing that. The semaphore value is 
the current number of elements in the queue. Reading from the queue is:

semaphore s, mutex m, element e, queue q

sem_wait(s)	/* Blocks only if the queue is empty */
e = queue_pop_left(q)

Writing consists of

queue_push(q, e)

The mechanism is a bit more complicated if one needs to handle the case 
where the queue can be full and one wants to block.

Also note that between the call to sem_wait() and mutex_lock() another 
thread could lock the mutex. This is not a problem. It only means that 
the second thread to wake up gets the first element the first gets the 
second. Something similar happens when one is writing.

Each mutex already has a queue of threads waiting for it, meaning that 
if multiple threads are blocked on mutex_lock, the first one should be 
woken up by mutex_unlock, and "sema" implements semaphores on top of 
mutexes, so they should behave similarly.

I'm curious as to the application of this, since RIOT does not run on 
multiple processor systems, what is the advantage of this approach over 
serial processing in a single thread (other than bypassing blocking calls).



On 07/12/2018 09:58 AM, Gunar Schorcht wrote:
> Hi,
> what would be the best way, if there is one, to use the existing
> mechanisms to implement a message queue that is not bound to the
> receiving thread?
> What I'm looking for is a message queue that can be used by a number of
> threads to send messages to and receive messages from the shared queue,
> as it is possible in FreeRTOS, for example.
> Regards
> Gunar
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

More information about the devel mailing list