Boost logo

Boost :

Subject: [boost] [rfc] lockfree API/naming suggestions
From: Tim Blechmann (tim_at_[hidden])
Date: 2011-11-15 04:18:15


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.

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.

any thoughts/comments?

thanks, tim


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk