Why doesn't ConcurrentQueue.Count return 0 when IsEmpty == true?

Question

I was reading about the new concurrent collection classes in .NET 4 on James Michael Hare's blog, and the page talking about ConcurrentQueue<T> says:

It’s still recommended, however, that for empty checks you call IsEmpty instead of comparing Count to zero.

I'm curious - if there is a reason to use IsEmpty instead of comparing Count to 0, why does the class not internally check IsEmpty and return 0 before doing any of the expensive work to count?

E.g.:

public int Count
{
    get
    {
        // Check IsEmpty so we can bail out quicker
        if (this.IsEmpty)
            return 0;

        // Rest of "expensive" counting code
    }
}

It seems strange to suggest this if it could be "fixed" so easily with no side-effects?

Answer 1

ConcurrentQueue<T> is lock-free and uses spin waits to achieve high-performance concurrent access. The implementation simply requires that more work be done in order to return the exact count than to check if there are no items, which is why IsEmpty is recommended.

Intuitively, you can think of Count having to wait for a timeslice when no other clients are updating the queue, in order to take a snapshot and then count the items in that snapshot. IsEmpty simply has to check if there is at least one item or not. Concurrent Enqueue and TryDequeue operations are changing the count, so Count has to retry; unless the queue is transitioning between the empty and non-empty states, the return value of IsEmpty isn't changed by concurrent operations, so it doesn't have to wait.

I wrote a simple multi-threaded test app which showed that Count was ~20% slower (with both constant contention and no contention); however, both properties can be called millions of times per second so any performance difference is likely to be completely negligible in practice.

Answer 2

Let me show you an overstating example:

public bool IsEmpty
{
   get { /* always costs 10s here */  }
}

public int Count
{
   get { /* always costs 15s here, no matter Count is 0 or 1 or 2... */  }
}

If they implement the Count property like this:

public int Count
{
   get
   {
       if (IsEmpty) return 0;
       //original implementation here
   }
}

Now when the final Count is 0, it costs 10s(5s less than before!great!), but for those Count is 1/2/more, it costs more than before, because checking IsEmpty costs time! So the optimization is not a good idea, because IsEmpty takes time. It will be good if IsEmpty is reading from a field directly.

EDIT I checked the implementaion of both IsEmpty and Count via reflector, both are expensive. Obviously checking IsEmpty for 0 count only will reduce the average performance speed.

Answer 3

Understanding how concurrent structures work is very important.

if (isEmpty()) ...//do whatever

if you have concurrent structure the check is close to no-op since everything can change between isEmpty and any subsequent operation.

Count iterates through the nodes (have not used c# for almost 6 years, but the java analog does the same) to calculate, so it is an expensive call. Straight answer: Checking isEmpty before Count will incur additional memory fence and effectively achieve nothing. Edit: if unclear. Count when the queue is empty costs exactly as isEmpty, however it costs a lot when the queue is not!

Count similar to isEmpty for concurrent structures has little to no meaning since the result of the call may not be useful and greatly changed.

Answer 4

IsEmpty provides some thread concurrency that if you obtain the Count value and compare it, its on your thread, but the queue could be changed.

MSDN says:

For determining whether the collection contains any items, use of this property is recommended rather than retrieving the number of items from the Count property and comparing it to 0. However, as this collection is intended to be accessed concurrently, it may be the case that another thread will modify the collection after IsEmpty returns, thus invalidating the result.