How to access object created by another thread?

Asked

Viewed 1,401 times

2

It is possible to access an object created by another thread?

  • 3

    Yes, it is. The same way you access an object created in the same thread. The only thing that should be noted is that if the object is changeable it can create problems if the access is concurrent and needs special care and perhaps locking, which may make its use unfeasible. https://answall.com/q/1946/101

  • @bigown I think your comment should be an answer.

  • @Renan posted.

3 answers

2


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

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

If the object is in the stack may be a problem trying to access it as a reference in some situations because it may not even exist anymore. But in general stack are copied to another method independent of this method running in another thread, then despite having the same value happens to be another object. It is very easy to work with these objects because they become independent and in threads each one will be on his own stack. This is the case of all types per value. But you also don’t have to do anything special to access the objects of stack, provided that it accesses the object itself stack. If you don’t use one ref in an object by value is guaranteed that it is in the same stack since there will be a copy.

Object immutable 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 the string.

If the object is changeable it can create problems if the access is competitor and then needs special care and maybe locking, which may even make its use unfeasible and become slower than without the use of thread. Behold It’s always guaranteed that a multi-threaded application runs faster than using a single thread?.

Has possible optimizations but are rarely needed.

Almost always prefer to use Task and not Thread.

See more in What is the difference between async, multithereading, parallelism and competition?.

  • Dear Mustache, thank you for the lesson. But (I guess I didn’t elaborate the question right), you didn’t give an example of how to do it in C#, because I’m getting an "exception" from the debugger when trying to access the object from another thread. (no competition problems)

  • @Paul in fact his question speaks nothing of it, can ask another question by putting the relevant code and what the error.

  • It’s not an error. I’m actually accessing an object created by another thread, and the Visual Studio debugger is indicating this as invalid operation. I wanted to know how to fix.

  • I mean, it’s a mistake. You have to post everything I told you, without it we can’t guess.

  • Okay. I’ll try to be more specific.

0

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

The easiest way to give one Invoke is:

Examples

Inside your Windows Form:

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

On a screen component:

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

0

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

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

It’s quite common for you to hear of UI Thread, that is the thread responsible for everything that happens in the program UI and only it should modify the UI.

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

Actually this is not even an error, this is an extra check that Visual Studio activates in Debug mode, this is done through the Control.CheckForIllegalCrossThreadCalls, he’ll always be true when debugging, if you run the program without debugging this value will be false and he shouldn’t shoot Exception.

Only that 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 be detected.

But the reason Visual Studio modifies this property at debug time is basically so Visual Studio can tell you, "Look, you shouldn’t be doing this," and it does this because the UI behavior when modified outside the thread that created it is not defined, anything can happen.

I have seen a case of a person who filled a Datagridview by another Thread and on his PC it worked, but when going to production the Datagridview did not show anything, it did not render correctly, appeared only parts of the headers without any text, and that is what is the undefined behavior, time it can work, time does not, and there is no standard for it, there is no fixing it because it is not a bug itself, the bug is in using control of another thread.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.