Threading: Backgroundworker vs Invoke [VB.NET]

NeuralJack

Centurion
Joined
Jul 28, 2005
Messages
138
I've been upgrading lots of my old .NET 1.0 code to .NET 2.0 and there are a few more problems than I had thought. Seems I was making all sorts of unsafe calls to update form controls from different threads.

I read this informative article which was recommended on another thread here and it helped me out a lot : http://www.devx.com/dotnet/Article/11358/0/page/1

Anyway, I've figured out how to do it safely with Invoke and delegates and it seems to be a relatively small amount of code to do that. But, I had a few questions though about the whole thing.

- First of all, I really dont understand why a call to a control from another thread is 'unsafe'. I mean the only thing that i can think of is if you're programming like a fool and you have 2 threads trying to write a lot to the textbox at the same time. It seems that there are many ohter mistakes that you can make while programming... why have they decided to police this one? Why are controls handled differently than say a simple user made Public String variable which can be accessed by many different threads at once (user made public variables are not policed).

- Why does updating the .text property seem to need invoking but updating the .backcolor and many other properties of the control do not need invoking - at least according to the debugger.

- I've read some about the backgroundworker as well. It looks like you need different separate subroutines for each backgroundworker(DoWork, ProgressChanged, RunWorkerCompleted)? Does this mean that if i wanted to run 5 different threads i'd need 5 different backgroundworkers? I wonder if they use more system resources than a simple Invoke would. The only reason i ask about the backgroundworker is because 2.0 documentations says its the preferred way to update controls from other threads these days. It seems the backgroundworker would require more code to do what i'm doing, although i may just not have a good grasp on it yet.
 
Last edited:
For some background reading (a series of 5 parts)
http://blogs.msdn.com/oldnewthing/archive/2005/10/10/479124.aspx
http://blogs.msdn.com/oldnewthing/archive/2005/10/11/479587.aspx
http://blogs.msdn.com/oldnewthing/archive/2005/10/12/480064.aspx
http://blogs.msdn.com/oldnewthing/archive/2005/10/13/480569.aspx
http://blogs.msdn.com/oldnewthing/archive/2005/10/14/481043.aspx

It seems that there are many ohter mistakes that you can make while programming... why have they decided to police this one?
I think this is a case where they know there is a potential problem and that it can be quite subtle; in the past they have published guidelines and those have been ignored, making the tools default to a 'best practice' will at least make people aware of the issue.

When it comes to which properties / methods do and don't require invoking the safest approach is to assume all need invoking. You may get away with them in testing or on particular hardware platforms but sooner or later you run the risk of getting burnt, the increase in dual-core systems is only going to increase the potential of a problem occurring.
 
Thanks again PD. I suppose i'll invoke every property and method of a control from now on, when from another thread. I'll probably stick with Invoking instead of backgroundworker too, until i see a reason to move to backgroundworker.

Also the last article on object cleanup was informative. I'm going to read up more on it so that i see exactly which objects need cleaned up. I have disposed of most big objects like streamwriters but not sure if anything else needs cleaned up.



PlausiblyDamp said:
For some background reading (a series of 5 parts)
http://blogs.msdn.com/oldnewthing/archive/2005/10/10/479124.aspx
http://blogs.msdn.com/oldnewthing/archive/2005/10/11/479587.aspx
http://blogs.msdn.com/oldnewthing/archive/2005/10/12/480064.aspx
http://blogs.msdn.com/oldnewthing/archive/2005/10/13/480569.aspx
http://blogs.msdn.com/oldnewthing/archive/2005/10/14/481043.aspx


I think this is a case where they know there is a potential problem and that it can be quite subtle; in the past they have published guidelines and those have been ignored, making the tools default to a 'best practice' will at least make people aware of the issue.

When it comes to which properties / methods do and don't require invoking the safest approach is to assume all need invoking. You may get away with them in testing or on particular hardware platforms but sooner or later you run the risk of getting burnt, the increase in dual-core systems is only going to increase the potential of a problem occurring.
 
Back
Top