No, those buffer examples are not nearly equal to a queue and will never ever "replace" queues in producer/consumer.
The most important advantage of queues for producer/consumer (which none of the other buffer mechanics share) is that it works eventbased to notify the reader that data is available. So if you would simply replace the queue by overly elaborate buffer mechanics as you attached to your last post, you will lose a great deal of the the purpose using producer/consumer.
So, to compare both mechanics:
- Queue works eventbased, whereas the buffer example does not.
- Queue has to allocate memory during runtime if more elements are written to the queue than dequeued. This is also true for the buffer (it has to be resized).
- Since the buffer is effectively simply an array with overhead, memory management is getting slow and messy with increasing memory fragmentation. Queues perform way better here (but have their limits there too).
- The overhead for the buffer (array handling) has to be implemented manually. Queue functions encapsulate all necessary functionality you will ever need. So queues do have a simple API, whereas the buffer has not.
- Since the buffer is simply an array, you will have a hard time sharing the content in two parallel running loops. You will need to either implement additional overhead using data value references to manage the buffer or waste lots of memory by using mechanics like variables. In addition to wasting memory, you will presumably run into race conditions so do not even think about this.
So this leads to four '+' for the queue and only one point where "buffer" equals the queue.
i hope, this clears things up a bit.
Norbert
Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
