uC/OS Queue Versus FIFO

[caleb]

I am trying to get a good grasp of why I would want to utilize FIFOs as opposed to message queues. The uCOSLibrary document doesn't describe much, but after searching around this forum I think I found that the main difference is that the contents of the FIFO structures are copied into the FIFO in a thread-safe way. Queues just pass a single pointer to the structure they are trying to send. This means that FIFOs can pass temporary stack variables while queues can only pass static heap variables (unless it can be gauranteed that the stack variable will still exist when the receive thread gets it, sometimes used with a handshaking member).

Couldn't the latter problem be solved by using the "new" keyword to change your stack struct into a heap struct, passing its address through the queue, and having the receive thread call "delete" after its done with the struct?

I would guess that avoiding struct copying would be more computationally efficient, but I guess I would have to compare the copying-overhead to the new/delete-overhead.

What else should I consider?

[tod]

This is just my opinion, but I think you should consider NEVER having the task (or class even) that receives a pointer perform the delete if that pointer was created in another task (or class). The user of a class should never have to know this level of internal detail and be required to manage memory for a class they are communicating with. This is just asking for a memory leak. It also makes your code harder to maintain and reuse. At a minimum if I had to, I would reach for Boost and use a shared_ptr<> so that at least the memory management is automatic. And as a disclaimer I should point out I almost exclusively use mailboxes and semaphores for safe inter-task communication, so I'm not that knowledgable on Queues vs FIFOs.

[Ridgeglider]

Queues point to the data; fifos hold the data, usually as a struct. Because of this, loading and unloading fifos can take time. Think twice if you use them in an ISR. Additionally, when you use fifos, you need to allocate memory for the fifo structs. Next, before posting to a fifo, you need to be sure there's space still available in the memory you've allocated. If so, you'll also need to provide a way to access that empty slot. See the examples for queues and fifos at C:\nburn\examples\StandardStack\RTOS. Have not dug into the queue internals, but while there are also clearly limits to the maximum number of queue entries, queue size is allocated by the system and generally you don't worry about whether there's space available when using queues.

Agree totally w/ Tod's comments about keeping new and delete together in the same task and/or class!!

[pbreed]

FIFOs are a specialized thing we use for moving network packets around.

Unless you use the buffers stuff ie "poolPointers" in buffers.h then I would pick queue over fifo...