|
Boost : |
From: Steven E. Harris (seh_at_[hidden])
Date: 2005-10-03 13:11:58
"Peter Dimov" <pdimov_at_[hidden]> 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:
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk