• 02/22/12 03:10 PM
    Sign in to follow this  
    Followers 0

    Producer Consumer Using Double Queues

    General and Gameplay Programming

    GameDev.net Admin

    • Download source - 4.02 KB

      License: Zlib


      Introduction



      Producer consumer is an old computer science problem. Many solutions have been proposed to solve this problem. The general approach is using a common queue. A single queue to which the producer writes data to and the consumer reads data from. Avoiding race conditions is done by locking the queue so that when the producer is writing, the consumer is not reading and vice versa.

      The problem with this approach is that whenever the producer puts data to the queue, it has to acquire a lock. Similarly whenever the consumer gets data, it has to lock the queue. This solution is inadequate on systems where the producer generates data in excess of a hundred thousand updates per second. In my opinion, a hundred thousand locks on the queue in one second is a huge performance penalty.

      Background



      Once while going over this conundrum with my better half, I was introduced to the concept of double queuing. Something similar to the double buffering used in graphics applications to avoid flicker. As far as my research goes, I was not able to find a similar solution to the producer consumer problem. In case this is duplication, my apologies. I would be indebted if you can point me to the original work.

      Double Queuing



      The solution proposed is very simple and elegant. Instead of using a single queue, we use two queues. At a given time, one queue is designated write queue and the other, the read queue. This helps us to avoid locking the queue while reading and writing to it. The producer is free to fill the write queue and the consumer is free to empty the read queue.

      When the consumer is done reading the read queue, the producer is blocked briefly and the queues are switched. Now the old read queue becomes the new write queue and the old write queue becomes the new read queue. After switching, if there is no data in the new read queue, the consumer is blocked. When the producer gets more data, it unblocks the consumer.

      The Code



      This solution makes use of Events for synchronization between the consumer and the producer. The producer code looks like this:


      public void ProducerFunc()
      {
      int data = 0;

      for (int i = 0; i < 10000; i++)
      {
      data += 1;
      MessageHandler(data);
      Thread.Sleep(m_Random.Next(0, 2));
      }
      }

      private void MessageHandler(int data)
      {
      m_UnblockHandlerEvent.WaitOne();
      m_HandlerFinishedEvent.Reset();

      m_CurrentWriteQueue.Enqueue(data);
      m_ProducerData.WriteLine(data); // logging

      m_DataAvailableEvent.Set();
      m_HandlerFinishedEvent.Set();
      }




      The ProducerFunc() is a thread function that is invoked 10,000 times. Every time MessageHandler() is called, it checks to see if it has been blocked by the consumer. If not, it resets the ManualResetEvent to indicate to the consumer that the producer has not yet finished. This is useful when the consumer is trying to switch the queues and wants to know if the producer is finished writing to the queue. The rest of the code is straight forward. Data is written to queue and an event is set to wake up the consumer incase it was blocked. Finally, an event is set to indicate that the producer is finished writing to queue.

      This is the consumer code:


      public void ConsumerFunc()
      {
      int count;
      int data;
      Queue readQueue;

      while (true)
      {
      m_DataAvailableEvent.WaitOne();

      m_UnblockHandlerEvent.Reset(); // block the producer
      m_HandlerFinishedEvent.WaitOne(); // wait for the producer to finish
      readQueue = m_CurrentWriteQueue;
      // switch the write queue
      m_CurrentWriteQueue = (m_CurrentWriteQueue == m_Q1) ? m_Q2 : m_Q1;
      m_UnblockHandlerEvent.Set(); // unblock the producer

      count = ;
      while (readQueue.Count > )
      {
      count += 1;

      data = readQueue.Dequeue();
      m_ConsumerData.WriteLine(data); // logging

      Thread.Sleep(m_Random.Next(0, 2));
      }
      Console.WriteLine("Removed {0} items from queue: {1}",
      count, readQueue.GetHashCode());
      }
      }




      The ConsumerFunc() is a separate thread function. When the function starts, it checks to see if the data present event has been set. If not, then it is blocked till we get data written by the producer. Once data is present in the queue, the consumer resets the event to block the producer and waits for the producer to finish. The current write queue is now cached for reading and the current write queue is switched. After the queue is switched, the producer is unblocked to enable it to start writing to the new write queue. Meanwhile the consumer is busy reading from the read queue. Once the queue is empty, the entire process is repeated.

      Points of Interest



      On further discussing this solution with others, I was told using synchronization events causes more performance problems than using lock. What do you think about that argument? Can you shed some light on this from your experiences with lock and synchronization events?

      About the Author



      Nothing to brag about! Just another passionate software developer!

      Work to make a living, don't live to work!



      License



      This article was authored by Ram Mohan Raja and reproduced for the benefit of our viewers under the terms of the Zlib license.
    0


    Sign in to follow this  
    Followers 0


    User Feedback

    Create an account or sign in to leave a review

    You need to be a member in order to leave a review

    Create an account

    Sign up for a new account in our community. It's easy!


    Register a new account

    Sign in

    Already have an account? Sign in here.


    Sign In Now

    Ectara

    • 5
      
    0

    Share this review


    Link to review
    DangerDoom

    • 5
      
    0

    Share this review


    Link to review