Boost logo

Boost :

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

Dave Abrahams
BoostPro Computing

Boost list run by bdawes at, gregod at, cpdaniel at, john at