Re: [boost] [lockfree review] rfc: naming and interface

Subject: Re: [boost] [lockfree review] rfc: naming and interface
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2011-07-24 00:25:53

On Sat, Jul 23, 2011 at 11:03 AM, Dave Abrahams <dave_at_[hidden]> wrote:
>
> on Thu Jul 21 2011, Joshua Juran <jjuran-AT-gmail.com> wrote:
>
>> 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.
>
> HTH,
>
> --
> Dave Abrahams
> BoostPro Computing
> http://www.boostpro.com
>

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
- fail/overwrite/wait on overflow, fail/wait on underflow
- growing/shrinking
- etc

I don't think all options are of the same importance - ie array vs
node vs hybrid isn't as important to me as mpmc vs spsc (because the
underlying data structure is an implementation detail, but mpmc vs
spsc means whether it will work correctly or not in a given
situation). But often the choice between vector vs list, etc is the
implementation details (which lead to key runtime characteristics) and
not a difference in interface.

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.

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.

Alternatively, even without using templates for selection, we should
"leave room" for more queues and other data structures.

And if the ringbuffer is a type of queue it should be named as such -
it is a spsc_queue I think?

Or queue could be a sub-namespace?  lockfree::queue::ringbuffer<>;
lockfree::queue::mpmc<>; etc?

Tony