Threading and DisplayConduit

Rhino Developer
1

I have an app that uses a display conduit, works well. I am adding a separate task that has some communication activity, that I would like to do on a separate thread than the main(which handles the UI). It also draws geometry based on that, so I have put it on a separate thread. This thread instantiates its own DisplayConduit. The threads don’t need to share any memory(at least for this purpose, maybe in the future). Are there any thread safety issues with this? It seems so; in one of my event driven draw methods, I get an error that the collection changed during enumeration. I can solve this by changing the collection to one of the ‘concurrent’ types in .NET. But I don’t see how its getting changed.

So the question is, should this be a thread safe approach(meaning my error is caused by something else)? Should placing the two conduits on different threads, each only accessed by itself, be safe? Or is there an issue with having two conduits on different threads? I don’t fully understand the rhino event model…which thread is calling the events? Main? My thought is that while I iterating the collection, and drawing things(triggered by an event) the other thread was changing them? But each thread fills its own collections, so I am not sure how this happens?

One clue which is odd, is I have “show threads” turned on in VS. When the error hits, its always the main thread stating its collection has changed. In fact if I set a breakpoint in this method filtered for the secondary thread, it never hits. But I created object IDs in the watch list for the two display conduits, and they are independent (if that is enough to tell). The second conduit draws fine…so it must be working. Its like I just can’t “see” it working. But mostly I just want to learn a bit more about whether this is odd or not.

Edit:
I just saw this:

I always took this to mean “mess with the controls”, in my case wpf. But does “UI” include drawing in the pipeline? If so, that would imply my worker thread needs to modify the main threads display conduit, not create its own…just seems really limiting(there is a large section in the display conduit introduction devoted to not “messing” with other peoples conduits…I assume those could be threaded?)

2

All display code runs on the main UI thread. It’s not even possible to have a conduit executing it’s draw functions on different threads because the display pipeline is what is calling the conduit draw functions at the appropriate times and the pipeline’s draw function is occurring on the main UI thread.

You can perform whatever calculations you want on a separate thread, but you always perform conduit drawing on the main thread.

3

That makes sense then, since the main thread triggers the event which the delegates are subscribed to, they are called by the main thread. So I am not as experienced with multi-threading clearly. I was also completely mistaken as to where the conduit exists; its owned by the object that holds a ref to the worker thread, not the thread itself.

So, understanding that, I simply have two display conduits, both being called on the main thread. That’s perfectly normal I am guessing, and any attempt to put one on another thread is both misguided and not going to work.

And that explains the issue then, I have a draw thread running on main and if a draw method takes too long, its collection gets changed by the worker thread before it finishes(bad news). So System.Collections.Concurrent it is! Apparently these take a snapshot of the collection, and generally I haven’t had much trouble with them(other than finding it odd that ConcurrentBag has no Clear().) Any other tips?