11

So far during my experience in Windows Phone 7 application development I notices there are different ways to runs an action in an asynchronous thread.

  1. System.Threading.Thread
  2. System.ComponentModel.BackgroundWorker
  3. System.Threading.ThreadPool.QueueUserWorkItem()

I couldn't see any tangible difference between these methods (other than that the first two are more traceable).

Is there any thing you guys consider before using any of these methods? Which one would you prefer and why?

Mo Valipour
  • 13,286
  • 12
  • 61
  • 87
  • You mean other than the obvious Threads vs ThreadPools discussion? – Tudor Nov 08 '11 at 21:20
  • It arguably depends on what you are trying to do, you have listed 3 very different threading models (basic, UI and managed pool), have you read MSDN etc... http://www.albahari.com/threading/ http://msdn.microsoft.com/en-us/library/aa645740(v=vs.71).aspx – Lloyd Nov 08 '11 at 21:21
  • @Lloyd Actually a Bgw runs on top of the ThreadPool and in SL threads are usually UI related, so 2 == 3 – H H Nov 08 '11 at 21:30
  • Well the preference of each in Windows Phone development is the subject of this question. – Mo Valipour Nov 08 '11 at 21:32
  • @Henk hmmm true but they are still 3 seperate threading models, even in Silverlight. – Lloyd Nov 08 '11 at 21:35

4 Answers4

15

The question is kinda answered but the answers are a little short on detail (IMO).

Lets take each in turn.

System.Threading.Thread

All the threads (in the CLR anyway) are ultimately represented by this class. However you probably included this to query when we might want to create an instance ourselves.

The answer is rarely. Ordinarily the day-to-day workhorse for dispatching background tasks is the Threadpool. However there are some circumstances where we would want to create our own thread. Typically such a thread would live for most of the app runtime. It would spend most of its life in blocked on some wait handle. Occasionally we signal this handle and it comes alive to do something important but then it goes back to sleep. We don't use a Threadpool work item for this because we do not countenance the idea that it may queue up behind a large set of outstanding tasks some of which may themselves (perhaps inadverently) be blocked on some other wait.

System.ComponentModel.BackgroundWorker

This is friendly class wrapper around the a ThreadPool work item. This class only to the UI oriented developer who occasionally needs to use a background thread. Its events being dispatched on the UI thread makes it easy to consume.

System.Threading.ThreadPool.QueueUserWorkItem

This the day-to-day workhorse when you have some work you want doing on a background thread. This eliminates the expense of allocating and deallocating individual threads to perform some task. It limits the number of thread instances to prevent too much of the available resources being gobbled up by too many operations try to run in parallel.

The QueueUserWorkItem is my prefered option for invoking background operations.

Mo Valipour
  • 13,286
  • 12
  • 61
  • 87
AnthonyWJones
  • 187,081
  • 35
  • 232
  • 306
  • Good answer. Just wanted to add that ThreadPool.QueueUserWorkItem and the BackgroundWorker both work with background threads. That means that the threads will be terminated immediately when the app is shut down. If you need to do work on a different thread and it must complete regardless of whether the user exits the app then you need to use the Thread class directly and set IsBackground to false. – calum Nov 09 '11 at 09:15
  • 1
    @calum: Good point however I'm note sure what would happen if the application is exited in WP7/Silverlight. Whilst the `IsBackground` property of the `Thread` class is supported according the documentation "there is no difference in behavior between the two". – AnthonyWJones Nov 09 '11 at 12:49
  • mmm... that may actually explain some random data coruption that I was noticing. I guess I need to run some tests to see what really happens. Thanks for the heads up. – calum Nov 09 '11 at 13:00
1

It arguably depends on what you are trying to do, you have listed 3 very different threading models.

  1. Basic threading
  2. Designed for applications with a seperate UI thread.
  3. Managed thread pool

Have you read MSDN etc...

http://www.albahari.com/threadin

Http://msdn.microsoft.com/en-us/library/aa645740(v=vs.71).aspx

Lloyd
  • 2,932
  • 2
  • 22
  • 18
  • Well the preference of each in Windows Phone development is the subject of this question. – Mo Valipour Nov 08 '11 at 21:31
  • I would still question what are you doing, performing some form of client server interaction that may not upodate the UI, loading data in the background that does update the UI or firing off a method call that can be run when there is a free thread (arguably not transactional) and may or may not update th UI. – Lloyd Nov 08 '11 at 21:38
  • Is updating UI a major concern? Can we not use Deployment.Dispatcher to update the UI in any background thread? – Mo Valipour Nov 08 '11 at 21:47
  • 1
    Silverlights UI is largely resource dependant so any operation that takes resources from the UI can, and will effect its performance. If you have a basic LOB application then it may not be an issue marchalling calls back to the UI however if you have a dynamic UI that is subject to user input and animation then you will need to look at how and when you manage threading resources. – Lloyd Nov 08 '11 at 21:57
  • BTW when I say "resource dependant" I mean it is constrained by the Silverlight framework and CLR compared to the Windows .Net Framework. – Lloyd Nov 08 '11 at 22:07
1

You don't state "what for", but

  1. Basic Thread - quite expensive, not for small jobs
  2. Backgroundworker - mostly for UI + Progressbar work
  3. ThreadPool - for small independent jobs

I think the TPL is not supported in SL, which is a pity.

H H
  • 263,252
  • 30
  • 330
  • 514
0

The background worker tends to be better to use when your UI needs to be update as your thread progresses because it handles invoking the call back functions (such as the OnProgress callback) on the UI thread rather than the background thread. The other two don't do this work. It is up to you to do it.

Wizetux
  • 756
  • 3
  • 12