CODEWITHSUNDEEP
c#silverlightwindows-phone-7
Mo Valipour
Mo Valipour

Reputation: 13496

Background Threads in Windows Phone

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?

Upvotes: 11

Views: 10824

Answers (4)

AnthonyWJones
AnthonyWJones

Reputation: 189555

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.

Upvotes: 15

Henk Holterman
Henk Holterman

Reputation: 273854

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.

Upvotes: 1

Lloyd
Lloyd

Reputation: 2942

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

Upvotes: 1

Wizetux
Wizetux

Reputation: 756

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.

Upvotes: 0

Related Questions