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

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 
prevents this)

> - 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-
time error.

> 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.

cheers, tim