2

I found the article regarding what I want to implement at Queue implementation in C#. But the article is based on .Net 4.0. and MSDN website has very simple example only. so decided to post this here.

That is, I'd like to implement that a thread displays a string asynchronously in dos prompt window by taking the string from a queue. Another thread might add additional strings in the string queue asynchronously as well(string maximum entry is 20, once fill maximum entry, no more addition). And I'd like to run this application until the queue is empty based on .Net 2.0 or 3.5.(VS2008)

Queuing implementation looks simple because .Net provides it, but I don't know how to implement asynchronous part with this queue.

Thank you.

Community
  • 1
  • 1
spark
  • 531
  • 6
  • 17
  • You might find the accepted answer to this question interesting: http://stackoverflow.com/questions/530211/creating-a-blocking-queuet-in-net – ChrisWue Mar 23 '12 at 22:02
  • Based on what your doing "asychronus" as in getting notified on completion doesn't make much sense and "asychronus" as in non-blocking is probably not worth the complexity, so eventough Aren's answer doesn't quite do what you are asking it is probably the right way to go. – Yaur Mar 23 '12 at 22:44

1 Answers1

5

So what I gather is you want to use essentially the ConcurrentQueue but you're stuck in .NET 3.5 and cannot use it (because it doesn't exist).

This goes back to simple operation locking. You don't want two threads accessing the same object at the same time.

Before You Start: Read This book on C# Threading by Joseph Albahari

It goes over .NET Threading and even just skimming it will help you prevent running into bad threading mistakes.

There's 2 things you essentially need to do, so let's break this down:

Accessing the Queue safely

You can use the Generic Queue<T> Class to implement your message queue, however all operations that change this object need to be handled safely.

The simplest form of doing this is using a Lock Statement.

lock(myQueue)
{
   myQueue.Enqueue(message);
}

You must lock around all operations, so the three you should need are .Enqueue(...), .Dequeue() and .Count since they all access data.

This will prevent you from running into multi-threading problems with queueing/dequeuing your messages and life will be good.

Waiting for a Message

To wait for a message you have a number of ways you can solve this. Most of them are outlined in the e-book i linked above.

The simplest is a Thread.Sleep Loop

while(appIsRunning)
{
    Thread.Sleep(100);
    lock(myQueue)
    {
        while(myQueue.Count > 0)
        {
           Console.WriteLine(myQueue.Dequeue());
        }
    }
}

Note: This is not the BEST way to do it, just the simplest example

What this does is simply schedules this thread to run again at least 100ms from now. (There's no gaurantee it'll run 100ms from now, just not before that time). Then it locks the queue so no writes can happen to it, it empties the queue and writes the lines to the screen then loops again.

If the queue is empty it'll just go back to sleeping.

The other solution is using a Pulse/Wait

Monitor.Pulse and Monitor.Wait are a ping-pong style thread control paradigm.

You can have your loop in the main thread Monitor.Wait() and when you add a message to the queue you can Monitor.Pulse() to release the lock it's to a waiting thread.

This is more semantically relevant but probably less efficient because your context switch is happening on demand for each message.

There's about 10 other ways to do this, most are outlined in that book but that's essentially the jist of it.

Please see Event Signaling Section of Joseph's Book for examples of all the signaling methods.

Aren
  • 54,668
  • 9
  • 68
  • 101