How to access object created by another thread?

Yes, it is possible. You access the same way you access an object created in the same thread . There is no differentiation between objects created in the same thread or another. At least when we're talking about heap . There is nothing special to be done.

The thread function is just allow more than one processing line and a memory environment unique for every application .

If the object is in the stack it can be a problem trying to access it as a reference in some situations because it may no longer exist. But in general objects in the stack are copied to another method independent of this method being run in another thread , then even though having the same value happens to be another object. It is very easy to work with these objects because they become independent and in different threads each will be in its own stack. This is the case for all types by value . But you also do not have to do anything special to access the stack objects as long as you access the stack object itself. If you do not use a ref on an object by value it is guaranteed that it is in the same stack since there will be a copy.

immutable object are also easy to handle because it is guaranteed that it will never be changed. If you need the object with a different state you need to create another object. An example is string .

If the object is mutable, it can create problems if the access is competitor and needs special care and maybe crash , which may even make it unusable and slower than without thread . See Is it always guaranteed that a multi-threaded application runs faster than using a single thread? .

You have possible optimizations but are rarely needed.

You'll almost always want to use Task and not Thread .

See more at What's the difference between async, multithereading, parallelism, and concurrency? .

You can use objects created in other Threads, but you should be careful not to access the same two-threaded object simultaneously unless the documentation for this object says it is safe to do (thread safe).

But there are cases where you can not do this, and this is not something C # itself, not even Windows, which is accessing the UI of a thread that was not the one that created it.

It is very common to hear about UI Thread , which is the thread responsible for everything that happens in the program's UI, and only it should modify the UI.

The error you say Visual Studio is giving you is very common in this case, if you are trying to modify the Windows Forms UI of another Thread.

In fact this is not even a bug, this is an extra check that Visual Studio activates in Debug mode, this is done through Control.CheckForIllegalCrossThreadCalls , it will always be true when debugging, program without debugging this value will be false and it should not trigger Exception.

Only you should never modify this value, I usually say if you change this value you will only hide a bug in your code that will be very difficult to detect.

But Visual Studio's reason for modifying this property at debug time is basically for Visual Studio to be able to tell you "Look, you should not be doing this", and it does this because the behavior of the UI when modified outside the thread that created it is not defined, anything can happen.

To access an object from another thread, you must give Invoke .

The easiest way to give Invoke is:

Inside your Windows Form:

this.Invoke(new Action(()=>{ /* TODO: Seu código aqui */ }));

In a screen component:

button1.Invoke(new Action(()=>{ /* TODO: Seu código aqui */ }));