2

I am looking for an equivalent of the concurrent_queue from Intel's tbb module in Rust. I have found some crates:

  1. multiqueue

  2. two-lock-queue

  3. crossbeam-deque

and even

  1. futures-pool

  2. thread-pool

I feel like they are all doing similar things, however in their docs it seems that they are using different algorithms for the implementation.

Though I don't know a lot about programming in C++, I am pretty sure that tbb's concurrent_queue is a very fast MPMC queue implementation. You cannot be close to that performance if you only wrap a queue container in a Mutex (which is tested by one of my friends).

Since the efficiency (both latency and throughput) is the main thing I care about, what should I use in Rust? The queue could be either bounded or unbounded and I probably need Acquire-Release ordering.

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
asdetrefle
  • 303
  • 1
  • 6
  • 14
  • 2
    Bounded or unbounded? And what kind of ordering guarantees do you need? Do you care about latency or only throughput? – CodesInChaos Mar 18 '18 at 12:37
  • 1
    Could be bounded or unbounded. I probably need Acquire-Release ordering if it is what you asked. And i care about latency as well. – asdetrefle Mar 18 '18 at 13:22

1 Answers1

2

I think the crossbeam::sync::MsQueue and the crossbeam::sync::SegQueue from the crossbeam crate have the same capabilities as the concurrent_queue you linked.

They are lock free queues that can be used in a non blocking way with push and try_pop.

This benchmark indicates that SegQueue is faster than MsQueue, but that may still depend on your use case.

FlyingFoX
  • 3,379
  • 3
  • 32
  • 49