Re: [boost] [lockfree review] rfc: naming and interface

Subject: Re: [boost] [lockfree review] rfc: naming and interface
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-07-21 07:42:03

Tim Blechmann wrote:
>
> the current names of the data structures are fifo, stack and
> ringbuffer. during the pre-review some people suggested to use
> different names, lifo instead of stack or queue instead of
> fifo. in general i think it is a good idea to use a consistent
> naming (probably fifo should be renamed to queue), but how does
> the ringbuffer come in? it is a queue as well, but with
> different characteristics (spsc and wait-free).

Consistency is good.  Internal consistency is better.

Either fifo and lifo or queue and stack.  Both sets use well understood terms.

Given that all three data structures are buffers of sorts, including "buffer" in the name of ringbuffer may be redundant, but it also implies contiguity.  "circular_buffer" has been suggested, but if ringbuffer deviates in significant ways -- beyond just being lock-free -- from boost::circular_buffer, then "circular_buffer," while consistent, would be misleading.

> data structure configuration:
> stack and fifo currently use 3 template arguments: T for the
> managed type, freelist_t as a tag to select the underlying
> freelist and Alloc as the allocator which is used for the
> internal nodes:
>
> template<typename T,
>          typename freelist_t = caching_freelist_t,
>          typename Alloc = std::allocator<T> >
> class fifo/stack;

The template parameters should all start with a capital letter and use CamelCase.  Thus, s/freelist_t/FreeList/.

> however i have been thinking about replacing it with a
> boost.parameter interface, something like:
>
> template<typename T, ... Options>
> class fifo/stack;
>
> with the options:
>
>   boost::lockfree::freelist_can_allocate<true/false> to disable
>   memory allocation during enqueue/push
>
>   boost::lockfree::allocator<> to specify the allocator

Anyone wanting to specify an allocator will not be put out having to specify the FreeList type, too.  Besides, template aliases in C++11 will make capturing specializations easy enough.  I don't think Boost.Parameter is warranted for such a trivial case.

> ringbuffer size:
> the ringbuffer currently has the signature:
>
> template<typename T, size_t max_size> class ringbuffer;
>
> if max_size is 0, the size of the ringbuffer can be configured
> at run-time with a constructor. this is not really the cleanest
> interface, but i would like to provide an interface, which
> supports both compile-time and run-time setting of the size.

Perhaps you could provide a tag type which indicates dynamic sizing.  Then, move your existing code to a base class, probably in the detail namespace, and provide a derivate that is specialized for non-zero size_t values and your tag type.  That is, make a size_t of zero be a compile time error, thereby requiring the tag type for the dynamic allocation case.  (The base class would use zero as you now do.)

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.