Re: [riot-devel] Message queue that is not bound to a reveiving thread
Hi Juan, thanks a lot for your answer. I will try your approach. 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). I'm just trying to use a vendor binary library for a RIOT port that is written for FreeRTOS. Therefore, I try to implement a small FreeRTOS to RIOT mapping layer which provides the required functions on top of the RIOT kernel. In FreeRTOS the queue mechanism is independent on tasks. You define a queue with a certain queue lenght and arbitrary item size. All exisiting tasks can send items to and receive items from this queue, also on single processor architectures. Regards Gunar Regards, Juan. 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@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Message queue that is not bound to a reveiving thread
Hi Kaspar, thanks a lot for your answer. Indeed mbox is providing some of my requirements. I could have come to that by myself if I had looked more carefully, especially because I already saw this mbox mechanism. Limitations for my use case are: - the queue length must be a power of two - objects in put to the mbox have to be of type msg_t and cannot have arbitrary item size - there is no option to put messages in front of the queue or the last written place Maybe, I did not formulate my question precisely enough. I would like to put copies of data items of arbitrary but fixed size in the queue. Regards Gunar Zitat von Kaspar Schleiser : Hi Gunar, On 07/12/2018 09:58 AM, Gunar Schorcht wrote: 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. Does mbox suit your needs? Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Message queue that is not bound to a reveiving thread
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 */ mutex_lock(m) e = queue_pop_left(q) mutex_unlock() Writing consists of mutex_lock(m) queue_push(q, e) mutex_unlock(m) sem_post(s) 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). Regards, Juan. 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@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
