We have an application that runs perfectly on a mono-core computer, but when run on a multicore computer, an exception is thrown in GoDiagram, stating that a collection was modified during a for-each, deep within GoDiagram painting (something like GoLayer.paint, I’m not sur, I can check if it may help).
At the same time, the diagram is replaced by a rectangle with a red border and its diagonal drawn in red too.
When I set the process affinity so that it runs on only one processor, the problem disappears.
The problem might be on our side, or on GoDiagram side, I don’t know for sure. But I’d like to have some information on multicore support for GoDiagram.
We have been developing on multi-processor machines for at least two years. We have been developing multi-threaded applications using GoDiagram for at least four years: witness the WebWalker sample app.
One of my machines has a dual core AMD 64 processor which dual boots both regular Windows XP and XP 64.
The most common problem is when you modify a Brush or Pen after it has been used. That can definitely cause problems, even in single-thread apps, but more so in multi-thread apps, and especially in multi-thread apps on a multi-processor machine.
GoDiagram is not thread-safe, but it does have some built-in mechanisms to help avoid some of the common threading problems. However it sounds like you are modifying a collection in one thread that the GoView thread is using to traverse the document/layers/objects being displayed. GoDiagram does NOT do any synchronization on collections, especially not in performance-important parts of the code such as painting.
Well, it seems the problem was on our part. We had another thread that updated the diagram based on notifications from our model. And in some cases, we forgot to add the call to GoView.Invoke so that this update happened in the GoView thread.
By the way, if we do the same kind of mistake with a classical .NET control, we usually get an exception that may be quite usefull to solve this kind of problems. Would it be possible to add some check (at least in debug mode, so as not to impact performances) to emit the same exception in GoDiagram ? I guess this might have something to do with calling InvokeRequired.
Well, one thing GoDiagram already does is that the GoView’s GoDocument.Changed event handler does check Control.InvokeRequired. If it is true, then it queues up the GoChangedEventArgs for delivery on the GoView’s event queue. This avoids a lot of problems.
However, that doesn’t help for things like collection modifications. I need to think about your suggestions.