Home/ Questions/Q 6833763
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T23:01:11+00:00

So far during my experience in Windows Phone 7 application development I notices there

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0