>> Has anyone ever seen a shared circular queue used in multi-tasking?
> Yes. I work on a vendor product that uses a circular queue where > multiple address spaces are adding to the queue and another address > space reads from the queue. > The reader reads until the 'next to be processed' matches the 'next free > slot'. It always checks and maybe waits for the ecb in the item slot > before it reads the slot. > There is special logic during the add process to handle a "queue full" > condition. (And, yes, I have seen it triggered.) This design should never be used in a critical component. I'm not surprised that you've seen "queue full". It occurs because of the circular queue design which eliminates many benefits of multi-tasking. Elements are processed sequentially instead of FIFO. Using an ECB in every element means the elements from higher priority tasks must wait on the slowest task (even worse in multi-address spaces). If the system get's heavily loaded, you might have a long batch address space that is swapped out causing major delays. You'll have elements queueing up until this slow task finally get's swapped back in. The second problem is abend recovery or storage overlay's which could potentially disable the product. I've worked on products where this is not tolerated. A real queue may lose a few elements but at least the system keeps running until you complete critical work and cleanly restart the system. As an FYI, the reader task could use the ECB instead of comparing "next to be processed". Also CS is not needed for "next to be processed" because only the reader task updates it. Jon.
