"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. The code uses ACE's mutex, condition, and lock ("ACE_Guard") classes, but the translation to a more boost-like set of primitives would be trivial. Find the code at http://www.panix.com/~seh/temp/two_lock_queue.hh http://www.panix.com/~seh/temp/error.hh http://www.panix.com/~seh/temp/unconditional_pop.hh I have mentioned some design rationale for this class before: http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/1c8... Note the following types: o two_lock_queue::const_front Permits const access to the head element (via get()) o two_lock_queue::front Permits non-const access to the head element (via get()) Permits popping the head element once (via release()) o two_lock_queue::renewable_front Permits non-const access to the head element (via get()) Permits popping the head element (via pop()) Permits advancing to the next element (via next()) Additionally, the queue exposes these member functions: o pop_front o push_back o interrupt (optional) I hope there are some ideas in there worth comparing or borrowing. -- Steven E. Harris