Steven E. Harris wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
I appreciate any comments on the interface
I have a related two lock queue class I wrote a few years ago that uses a special set of nested handles to grant certain visibility and modification privileges to clients.
These handles, called "front" or similar variations, are necessary to see values at the front or head of the queue. Creating one encapsulates blocking and waiting for at least one element to be present, holding of the head lock to prevent concurrent popping or mutation of the element, and optionally having the privilege to pop the current element and move to the next one before some other waiting client can.
Thanks, I'll take a look at your rationale link. One argument against your enhancements is that (to the untrained eye) they seem to mandate a lock-based implementation. I wanted to permit a lock-free implementation, if possible.