Well, BlockingCollection<T>
is really designed for parallel work, where you have multiple simulataneous "producers" and one consumer (using GetConsumingEnumerable()).
In this situation, you have no way to guarantee insertion order, so the ordering constraints aren't specified.
That being said, BlockingCollection<T>
works upon any IProducerConsumerCollection<T>
(specified in the constructor). If you don't provide one in the constructor, internally, it will use a ConcurrentQueue<T>
. This causes it to be FIFO, since it will actually be (internally) a queue. So yes, by default, it will be "guaranteed to be strictly FIFO if used in a single-producer, single-consumer fashion", at least in the current implementation. If you want to force this for future proofing (since the queue is an implementation detail), just construct it as:
var blockingCollection = new BlockingCollection<MyClass>(new ConcurrentQueue<MyClass>());
That will guarantee that it uses a queue now, and in the future (since the queue is an implementation detail).
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…