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