Re: [boost] [rfc] lockfree API/naming suggestions

Subject: Re: [boost] [rfc] lockfree API/naming suggestions
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-11-28 18:57:27

on Tue Nov 15 2011, Tim Blechmann <tim-AT-klingt.org> wrote:

> hi all,
>
> i am preparing boost.lockfree so that it can be merged to trunk. however i'd 
> request some suggestions, concerning interface and names:
>
> ringbuffer naming:
>
> there is a fixed-sized single-producer/single-consumer wait-free queue, which 
> is implemented as ringbuffer. the linux kernel uses the name `kfifo', the 
> jack-audio-connection-kit refers to it as `ringbuffer', herlihy/shavit discuss 
> it under the name `BoundedQueue'. the boost.lockfree implementation is 
> currently named `ringbuffer', but i could rename it before merging it into 
> trunk. suggestions:
>
> ringbuffer
> waitfree_queue
> spsc_queue
> bounded_queue
>
> personally i'd be in favor of `ringbuffer' (because i have been using this 
> name for years) or `spsc_queue' (because it makes clear that it doesn't 
> support multiple produces/consumers). but i'd be curious, what other people 
> suggest.

Well, "pipe" kind of captures the idea that it has limited capacity and
goes from here to there.  But it's probably better to go with
bounded_queue if that's accepted terminology.

> fifo/queue bounded push:
>
> fifo and queue can be configured to use a dynamically growing freelist for 
> memory management. in this case, the `push' operations may block if the 
> freelist is exhausted and a new node has to be allocated from the OS. 
> currently this can be avoided by a per-class policy.
> however it would be reasonable to move this policy from a per-class to a per-
> call policy.
>
> so instead of:
> queue<T, boost::lockfree::bounded<true> > q; T t; q.push(t);
>
> one could write:
> queue<T> q; T t; q.push_nonblocking(t);
>
> however this would imply 3 flavors of `push'
> * push, which may block during memory allocation
> * push_unsafe, which is not thread-safe (but faster)
> * push_nonblocking, which is guaranteed not to hit the memory allocator.
>
> so i am not sure, whether this introduces too much complexity into the
> API.

Under those names, I would say, "yech."  is this a single-producer or
multiple-producer queue we're talking about?  If single, it seems
meaningless to say a push operation is not thread-safe.  If multiple,
"not thread-safe" would indicate to me that it's being used in a
single-producer mode.  And what are the thread-safety characteristics of
push_nonblocking?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com