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