0

I've been having a lot of annoying problems with accessing bitmaps lately and I'm starting to think I need to re-evaluate the design of my application.

At present, I have one object that creates two others. One of these others provides a series of bitmaps (e.g. from a webcam) and the other provides a series of coordinate pairs (e.g. from a mouse or touchpad). The parent object has listeners for the events that the children objects generate. The events are have custom arguments which carry the new information (bitmap or coordinates) as a payload. For instance:

public class NewImageEventArgs : EventArgs
{
    public NewImageEventArgs(Bitmap image)
    {
        Image = image;
    }
    public Bitmap Image { get; private set; }
}

The listener methods in the parent object copy the payload to the object-level representation. When either listener (bitmap or coordinates) is triggered, they subsequently call a shared method, which uses both the bitmap and the coordinates to do some calculation.

private void PointerModule_NewPosition(object sender, NewPositionEventArgs e)
{
    this.p = e.Position;
    this.Invalidated();
}

It seems to me that my recurring problems with OutOfMemory and InvalidOperation ("Object is currently in use elsewhere") exceptions stem from the fact that each new event may be on a different thread. When a bitmap is being used on one thread, exceptions are raised when another thread tries to simultaneously access it.

Do I need to fundamentally change the shape of my program? Are there any precautions I can take to eliminate this type of problem?

Community
  • 1
  • 1
Tom Wright
  • 11,278
  • 15
  • 74
  • 148
  • Have you considered using a queuing architecture? Let the provider threads pop images to a FIFO queue and process them in a separated thread. – Magnus Johansson Oct 04 '12 at 11:49
  • @Magnus I'd be interested in seeing that expanded into an answer. In my case however, I'd probably want to put real-time performance ahead of processing each item. Is this possible in a queue? – Tom Wright Oct 04 '12 at 12:42
  • Well, I would argue that a multithreaded architecture using a ConcurrentQueue with multiple Consumers (and Producers) would run circles around a single-threaded "real time" design. Especially on a multicore system. Of course YMMV, it depends on the characteristics of the data etc, etc,... At the moment, I don't have the means of whipping up an example, but at least take a look at this: http://geekswithblogs.net/BlackRabbitCoder/archive/2010/06/07/c-system.collections.concurrent.concurrentqueue-vs.-queue.aspx – Magnus Johansson Oct 04 '12 at 13:01

1 Answers1

0

EDIT: I reread your question and I might have responded to a slightly different question than you've asked. However I fought the same problems with "Object is used elsewhere" exceptions and the lesson I learned is summarized in the link in the bottom. Neither bitmap.Clone() nor new Bitmap(source) creates deep image copy. This is causing the exceptions.

In my application I use pattern :

public class ImageProvider()
{
public event EventHandler LiveImageUpdated;
private object _currentImageLock = new object();

private Bitmap _currentImage;
public Bitmap CurrentImage
{ 
    get    
      {
       lock (_currentImageLock)
         {
            return DeepImageCopy(_currentImage)
         }
       }
     private set
     {
       lock(_currentImageLock)
       {
            _currentImage = value
       }
        if (LiveImageUpdated != null)
        {
          foreach (Delegate del in LiveImageUpdated.GetInvocationList())
          {
              EventHandler handler = (EventHandler)del;
              handler.BeginInvoke(this, EventArgs.Empty, null, null);
           }
        }
     }
}

}

And I asked this question : How to create a Bitmap deep copy

Application works without a problem. So basically I skipped the part with pushing new image as an argument and listeners are asking for deep copy of the image and they are not sharing images. Performancewise it works without a problem.

Community
  • 1
  • 1
Biggles
  • 1,306
  • 1
  • 12
  • 22
  • The answer seemed to be a combination of deep copying and moving the locking into the property itself (as shown in your answer). – Tom Wright Oct 05 '12 at 13:01