[boost] [rfc] lockfree API/naming suggestions

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