Need an explanation on Lifetime of Objects Created in a Thread

Question

I have a DevExpress GridControl bound to a BindingList.

I tried to modify the BindingList from a thread and this threw an exception, I googled it and found the following explanation:

This issue is not connected with the XtraGrid directly. Unfortunately, you can't change the grid's data source in a background thread since it will cause a lot of problems with synchronization. The XtraGrid may perform some operations with the underlying data source at the same time as your background thread changes it. In this case the grid may receive a Change notification later and will try to update rows from the data source which will cause the mentioned problem. This problem may occur in a lot of cases. For example, when a user edits data, groups it or the XtraGrid tries to recalculate the summaries. The only solution to this problem is to change the Grid's DataSource reference within a background thread (NOTE: You will need to implement it using the Invoke method). Said differently, within a background thread you should work with a local copy of the DataSource and pass its clone to the Grid's DataSource when necessary. In the attached example you will find a sample project which demonstrates this approach.

I tried what it said, resulting in this:

proxyWorker = new Thread(() =>
{
    //Clone the datasource into the thread
    BindingList<Proxy> newList = new BindingList<Proxy>(proxies);

    //Set the proxy source to the cloned datasource in the thread
    gcProxies.BeginInvoke(new MethodInvoker(delegate { gcProxies.DataSource = newList; }));

   //Logic here
});

proxyWorker.Name = "proxyTester";

proxyWorker.Start();

It works, but what I don't understand is what happens to the datasource after the thread ends? Isn't newList destroyed?

What I was thinking is that at the end I would reclone newList and set it back into proxies (the original datasource)

Answer 1

I think your confusion stems from the fact that you think a .NET object is associated with the thread that created it. That is not the case, all threads in a process share the same GC heap. A List<> object created in one thread isn't different from a List<> in another, it doesn't in any way keep the thread that created it alive.

What is an issue with threading is that there are a lot of classes that are not thread-safe. This is certainly the case for any UI component. What you can't do is assign a property of such a class object from another thread while that property value may also be used in the UI thread. Almost all of the properties of a UI component have that restriction. Data binding is particularly troublesome since the property assignments are not directly visible. You only set the DataSource, not all the other properties that the binding sets. Using Control.BeginInvoke or Dispatcher.BeginInvoke ensures that the property values are set in the same thread that created the control, thus solving the thread safety problem.

Answer 2

that's 'one on one' C# garbage collection

new list lives on, is referenced through the gcProxies.DataSource.

Until you run out of references to that list you're good.

Unless there are any specific 'cross-thread' concerns regarding the 'list' you're accessing cross thread or creating in one and using in another - all will work just nice.
Here you're just initializing and never using it again other than thru DataSource so all is fine.

hope this helps

EDIT: to answer on the comments, I'm simplifying a bit

Thread you incidentally created your object on, has nothing to do with the object's "life-cycle" - i.e. thread doesn't own the object. Application Domain does (which is out of the scope), but you can 'cross' thread boundaries or do whatever you want - but you 'just' need to synchronize your code/objects.