Subject: Re: [boost] [rfc] lockfree API/naming suggestions
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-11-29 10:56:20
on Tue Nov 29 2011, Tim Blechmann <tim-AT-klingt.org> wrote:
> hello dave,
>> > 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?
> spsc would have push and push_unsafe, mpmc an additional push_nonblocking.
>> 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.
> not quite: push_unsafe does not have to use any atomic operations. so it can
> be more efficient to use this method, when the program logic guarantees that
> no other thread currently accesses the data structure.
>> And what are the thread-safety characteristics of push_nonblocking?
> push_nonblocking has the same safety guarantees as push. however it also gives
> stronger guarantees concerning the real-time safety: push may block, if an
> internal node needs to be allocated, while push_nonblocking would simply fail.
> it is reasonable to have two different methods for that, because the same data
> structure may be accessed by threads with different real-time
If it were me, I wouldn't label anything "unsafe," since presumably even
the push you're calling unsafe is as threadsafe as int, and it seems
like the right prefix for the nonblocking one is "try_". I might use
("push", "atomic_push," "try_push") or if the use of the single-threaded
version is rare enough, ("single_thread_push"/"serial_push", "push",
Just some thoughts; hope they help.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk