In my WPF application, I want to do some work in a non-UI thread so as to avoid the UI from become not-responding. For that I did this:
var caller = new AsyncMethodCaller<Pattern>(this.SetPatternType);
caller.BeginInvoke(_patterns, null, null);
And the delegate is defined as,
public delegate void AsyncMethodCaller<in T>(IEnumerable<T> data);
My question is:
Does BeginInvoke()
create a new thread and the callback SetPatternType
runs in it? If so, how long this thread last?
Is this approach good in general? If not, what is wrong with it? And what potential problem(s) might I face?
I'm using C# 4.0 and Visual Studio 2010.
EDIT:
Also I need few guidelines regarding these:
When I should create a new thread myself and when should I make use of BeginInvoke()
? And when should I use DispatcherObject.Dispatcher.BeginInvoke()
object?
It is technically not a new thread
its a Threadpool thread, and it migth last longer than your process/program but might run some other threads asynch calls immediately it finishes yours. Check MSDN articles on Asynch Programming and Threadpool to get the complete details.
And depending on your interest check I/O CompletionPort for additional details.
Asynch programming is generally considered better than atleast synchronous code, but f you are on .NET 4.0 take a look at Task Parallel Library.
Based on Question Edit, when should I create my own thread?
It is always better to use BeginInvoke or Async programming compared to creating your own thread. Strictly create your own thread when you are sure that you need a dedicated thread doing some task/work continuously and you are clear about the synchronization mechanics needed by multiple threads in your application. Avoid creating new threads as long as you can unless you have a really compelling reason. You add a thread today and probably move on and after two years three developers see that an additional thread was added for some continuous stuff, they'll add few more and so on. Trust me I've seen this happening, therefore set the right practices (ie using Asynch methods) and people will try to follow that. I've seen applications with 150 threads, does that make sense on a dual core or quad core machine, I dont think so.
Just checked all the running processes on my Toshiba Laptop for such badly designed apps, Toshiba Bluetooth Manager wins the crown of worst designed program on my box using 53 threads. :)
It uses the thread pool - so it won't necessarily create a new thread, but it runs in a different thread to the calling thread (unless that's a thread pool thread itself which happens to finish its task before the delegate invocation is scheduled; it would be pretty unlikely to use the same thread).
Dispatcher.CurrentDispatcher is new stuff in WPF (kind of replaces InvokeRequired stuff in WinForms).
You can use Dispatcher to queue any updates you want to the GUI and it has different priorities you can choose from
see this MSDN link