C# multithreading

Question

Take a look at the code below. Assume that this is the ENTIRE class. I have not omitted ANY code. This is literally all it does.

If I instantiate this class in my main program loop and call myExample.Add(whatever) from time to time, do I need to worry about any problems caused by not locking around Dequeue() and Enqueue()?

public class Example<T>
{
    private Queue<T> q = new Queue<T>();

    public Example()
    {
        new Thread(() => 
        {
            while (true) 
            {
                if (this.q.Count > 0)
                {
                    var item = this.q.Dequeue();
                }
                Thread.Sleep(1);
            }
        }).Start();
    }

    public void Add(T val)
    {
        this.q.Enqueue(val);
    }
}

What happens if this.q.Enqueue(val) is called at the same time as this.q.Dequeue()?

Answer 1

It depends. :) If you call into Example with multiple threads, you will have a race condition between your check for the count of the queue and the dequeue. For example ...

T1 Call Example
T2 Call Example
T2 check Q.Count > 0 (yes)
T1 check Q.count > 0 (yes)
T2 dequeue
T1 dequeue OOPS!

If you don't call into example with multiple threads, then you will have no problem since you don't care what you take off, only that you take something off. If you cared what you took off, then the race condition between Add and Example would be an issue again.

Answer 2

I assume by

this.queue.Enqueue(val);

you mean

this.q.Enqueue(val);

?

If so, then yes, you need to perform some sort of locking. Collections aren't inherently thread safe. Considering that you're always removing from one thread, and always adding from another it MIGHT work ok, but why not play it safe?

Answer 3

Chris

Add a private static field

readonly static object lockObject = new object();

enclose the dequeue and enqueue with

lock(lockObject)
{
  //do stuff
}

for your lambda put it outside the loop

Answer 4

Since you're writing to the Queue via the Dequeue method you do need to lock it. Queues are thread safe for multiple readers but not multiple writers Queue thread safety.

Answer 5

I don't see why you think it might be safe.

My worry/assumption is that entering the Enqueue and Dequeue simultaneously (from two different threads) might corrupt the internal state of the Queue instance.

Answer 6

MSDN says that Queue is not thread safe: http://msdn.microsoft.com/en-us/library/7977ey2c.aspx

Answer 7

The short version is you must synchronize access to a queue if you expect it to function. There are obvious thread races in the Count/Dequeue, but more importantly no operation is guaranteed - the internal state could legitimately do anything, and is likely to be corrupted.

You would also want a way of exiting the thread eventually...

To write a blocking queue, see here: Creating a blocking Queue<T> in .NET.

Answer 8

Since you are explicitly creating a separate thread which modifies the Queue, it is not ever safe to call Add(), regardless of what thread you call it from.

You need to lock() the "if" statement block since it's not even safe to call q.Count, then lock again in the Add() method.