Re: [boost] [rfc] lockfree API/naming suggestions

Subject: Re: [boost] [rfc] lockfree API/naming suggestions
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-11-29 11:39:43

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-tp4042331p4119828.html
Sent from the Boost - Dev mailing list archive at Nabble.com.