Tim Blechmann-2 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.
I think that the type must contains whether it is safe to produce/consume from multiple threads. I will use the prefixes: spsc_, spmc_, mpsc_ and mpmc_. bounded and ring mean different things for me. A bounded queue will block when there is no more free space. A ring will override the first element of the queue when there is no more space. I don't know which is the semantics of the operations you are providing, but I gues that your implementing a bounded queue, so xxxx_bounded_queue should be ok. 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); I agree that the policy could be on the operation. 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. IMO, the push should corresponds to the expected behavior. As these queues are in a lockfree library, I would expect that the push is thread safe. I agree with Dave that try_ is a better name for a non blocking operation. I don't know in which cases the application can be sure that there is no thread safe issues, but in any case, the interface should be enough ugly to make it more difficult to use, as it is unsafe. thread_unsafe_push seems quite ugly, isn't it? ;-) Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/rfc-lockfree-API-naming-suggestions-tp404... Sent from the Boost - Dev mailing list archive at Nabble.com.