GQUEUES vs. gfxBuffers

[kengineer]

I'm looking into using the GQUEUE system for an application with uGFX and wanted to hear your opinions of the best uses (examples) of queues vs. buffers (gfxbuffers).

I'm looking for comparison of for operations that need to share data that occur on the same thread and operations in different threads as well as thread safety and advantages and disadvantages of each.

In this specific use case I would be sharing data with two functions on the same thread but I could see needing other uses in the future so want to be sure I choose the right architecture. It seems that GQUEUES would maybe be a good choice as they have a lot more flexibility and options for multiple applications but wanted to hear opinions as this doesn't seem like a topic that's been explored very much by other users on the forums. Thanks!

[David Kibble]

When I looked at this I took away that a buffer is really no more than a shared memory block. You can certainly use buffers as a means to move data between threads or functions but it depends what functionality you want. Queues are FIFO so preserve sequence which may be important to you. Also queues take care of next available and empty functionality. Mutex's can be used with both to control thread behaviour but generally I haven't needed them with queues other than for when I'm searching a queue and want to stop other threads adding / removing at the same time. Concurrent queue processing is fine, the get functions are atomic.

I think without knowing more about your requirements its hard to say which would be most appropriate. If you aren't sure and you don't need random access most of the time I'd go with queues. I'm using queues for command processing and message queuing and have found uGFX to be very solid. 

Dave

[inmarket]

GfxBuffers is designed to provide a pool of fixed size buffers that can safely be used accross multiple threads. Good examples of usage would be audio streaming (in and out), network buffers, disk buffers etc. it could also be used for message pools (but is not designed for message queuing).

Queues are more general in nature and are basically just a fifo with appropriate multi-thread handling. There are 3 forms of queus, async, fsync and gsync.

The difference between the three is what happens in failure situations eg async queues fail if you try to get from an empty queue. fsync queues will block in that situation until another thread puts an item on the queue. Similarly gsync will block in another fail situation (I can't remember exactly what off the top of my head - probably something to do with putting). Both fsync and gsync are extensions of async queues so the async calls will work on fsync and gsync objects when you want the non-blocking behaviour. uGFX itself makes good use of both async and fsync queues.

You are right, this probably deserves a wiki article.

I hope this discussion helps.

[Joel Bodenmann]

Well, I guess I'm a bit late to the party, but here are my two cents (which is really just copy-paste from the documentation) regarding the difference between the Async, GSync and FSync queues that @inmarket mentioned:

Quote

There are 3 types of queues:

• Asynchronous Queues (ASync) - Queue operations never block
• Get Synchronous Queues (GSync) - Queue Get operations block until something is placed in the Queue
• Fully Synchronous Queues (FSync) - Queue GET and Put operations block

This is also explained in the corresponding wiki article: https://wiki.ugfx.io/index.php/GQUEUE

[inmarket]

Thanks Joel for pointing to the correct documentation .