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

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
> constraints.

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",
"try_push").

Just some thoughts; hope they help.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com