[boost] [concurrent] Fast, lock-based queue implementation

[David Stone via Boost]

I have written a new concurrent queue that has a focus on high throughput.
You can check it out here:

https://github.com/davidstone/concurrent-queue

Some highlights of this queue:

* The bulk interface is faster than other queues for many common load
patterns
* Almost any element type is supported with very few requirements
* Supports any number of producers
* Supports any number of consumers (although it works best with only one)
* Can dynamically grow and shrink in memory as needed
* The interface allows for very little undefined behavior: for the most
part, as long as your special member functions like move constructors do
not reference the queue you are inserting into, you are fine
* Interface based on the pattern of moving values in and returning values
via return, rather than other queues which use reference output parameters
* Header-only
* Design should be fairly straightforward to verify for correctness
* Compiles warning free with a very high warning level on gcc and clang
* Does not have any errors under ubsan, asan, or tsan

I would like to submit this for inclusion in Boost if people find it
interesting and useful, but first I would like to get some feedback on the
design, implementation, documentation, tests, etc.

I have tested this exact version on Gentoo Linux under clang 4.0 and gcc
6.3.0. I will be testing out Visual Studio 2015 and 2017 in the near future
to ensure there have not been any regressions. I have run fundamentally the
same queue on Visual Studio 2012 (no longer supported due to C++14
features), Visual Studio 2015 (Windows Server 2008 R2, Windows Server
2012), gcc 4.9.1 (Red Hat 6 under developer toolset 3), gcc 4.9.2 (Red Hat
7), and clang 3.9.0 (Red Hat 7) for several years now with no issues, so it
is a fairly mature design.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Peter Dimov via Boost]

Post by David Stone via Boost
I have written a new concurrent queue that has a focus on high throughput.
https://github.com/davidstone/concurrent-queue

...

- If C++14 is required, why not use the standard thread/chrono facilities?

- Where can I see the benchmark results? You link to a fork of the
moodycamel repo, but I couldn't find the actual results.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[David Stone via Boost]

On Sat, Jun 17, 2017 at 10:26 PM, Peter Dimov via Boost <

Post by Peter Dimov via Boost
- If C++14 is required, why not use the standard thread/chrono facilities?

Excellent question that I should document. std::thread does not support
interruption, boost::thread does. I find this feature compelling enough to
justify using the boost version over the standard. The next best
alternative, as far as I know, is to do the equivalent of adding a "stop
processing messages" message to the queue. In particular, I found this to
work well together with
boost::scoped_thread<boost::interrupt_and_join_if_joinable>. The use of
boost::chrono instead of std::chrono is just to interoperate with
boost::condition_variable.

Post by Peter Dimov via Boost
- Where can I see the benchmark results? You link to a fork of the
moodycamel repo, but I couldn't find the actual results.

Oh, I must have forgotten to save those. I will re-run the benchmarks and
put the results in a document in the repo.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Peter Dimov via Boost]

Post by David Stone via Boost
On Sat, Jun 17, 2017 at 10:26 PM, Peter Dimov via Boost <

Post by Peter Dimov via Boost
- If C++14 is required, why not use the standard thread/chrono facilities?

Excellent question that I should document. std::thread does not support
interruption, boost::thread does. I find this feature compelling enough to
justify using the boost version over the standard. The next best
alternative, as far as I know, is to do the equivalent of adding a "stop
processing messages" message to the queue.

Natively supporting this mode of operation is not a bad idea in its own
right. This is sometimes preferable to the interruption approach because it
guarantees that the consumers will drain the queue before shutting down (and
that guarantee comes for free, no effort is required on part of the user, as
long as the producers are shut down beforehand.)

You will also need tests.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost