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:
> 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
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
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 http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk