Subject: Re: [boost] [lockfree review] rfc: naming and interface
From: Tim Blechmann (tim_at_[hidden])
Date: 2011-07-24 05:22:55
> >> I generally prefer plain English over acronyms -- especially since
> >> stack and queue are terms and concepts well-understood by computer
> >> scientists, but LIFO and FIFO may require mentally deducing which one
> >> is which. So my vote is on "stack" and "queue".
> >> As for "ringbuffer", I would consider shortening it to just "ring".
> > Not bad. Alternatively, consistency with the C++ standard would argue
> > for something like wait_free_queue.
but then, wait_free_queue or spsc_queue? spsc_queue may be better as there are
probably going to be more bugs of the sort `spsc data structure used for mpmc
operations' than `lock-free data structure used, but wait-free is required'
> We should imagine that more specialized queues will be added. So it
> would be nice to somehow be able to name them, or ask for them via
> template param.
> Here are just *some* of the options that can be combined in various ways:
> - single vs multiple producer and consumer (typically called
> spsc,mpmc,spmc,mpsc queues)
> - node based, array based, hybrid
> - bounded/unbounded
> - intrusive / non-intrusive
to add some more confusion: intrusive, but not ABA prone (if the program logic
> - fail/overwrite/wait on overflow, fail/wait on underflow
is `overwrite' reasonable? and there would be quite a number of options, how to
wait: spin, spin-and-yield(), wait for semaphore (it there were a
boost.semaphore), wait for condition variable
and if, we really want to go that way:
- fifo-ordered/lifo-ordered. then we won't even need the stack class and the
library could be renamed as lockfree_queue ;)
> Could (should?) this be done with template attributes? ie
> queue< spsc, bounded, intrusive > myQueue;
> Any params not given mean "I don't care, go with default". If you
> request a queue that is mpmc, hybrid, unbounded, shrinkable, waitable,
> and we don't have one yet, then it doesn't compile.
there are different opinions about this: some people say that different template
arguments should not conflict, while others say this is fine to throw a compile-
> Note also that they queues would probably have *almost* the same
> interface, but some functions like 'size()' might not exist depending
> on which combination you choose. Maybe that makes it a bad idea.
compile-time assertions can be thrown in this case. i am using this for the (to-
be-renamed) ringbuffer to ensure that the correct constructor is used when the
data structures is compiled as compile-time-sized vs run-time-sized.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk