Difference between Thread, ThreadPool & BackgroundWorker [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 9 years ago.

Improve this question

i many time call method with the help of thread like

static void Main( string[] args )
{
    Thread t = new Thread( MyFunction );
    t.Start();
}

static void MyFunction()
{
    //code goes here
}

and some time i use ThreadPool class also like

System.Threading.ThreadPool.QueueUserWorkItem(delegate {
    MyFunction();
}, null);

but i do not understand what is the difference between calling any method with the help of thread class or ThreadPool class

so i am looking a good discussion about what is the difference between Thread & ThreadPool class.also need to know when we should use Thread class to call a method and when ThreadPool class to call any method ? if possible discuss also with sample code with sample situation.

another very important question is that if i start multiple thread then my application performance will become low or bad ? if yes then tell me why...?

now also tell me what is BackgroundWorker class and how it is different from Thread & ThreadPool class. how far i heard that BackgroundWorker class also create a separate thread to run any method. so please discuss how it is different from Thread & ThreadPool class and when one should go for BackgroundWorker class.

here is small sample code of BackgroundWorker

private void button1_Click(object sender, EventArgs e)
    {
        BackgroundWorker bw = new BackgroundWorker();

        // this allows our worker to report progress during work
        bw.WorkerReportsProgress = true;

        // what to do in the background thread
        bw.DoWork += new DoWorkEventHandler(
        delegate(object o, DoWorkEventArgs args)
        {
            BackgroundWorker b = o as BackgroundWorker;

            // do some simple processing for 10 seconds
            for (int i = 1; i <= 10; i++)
            {
                // report the progress in percent
                b.ReportProgress(i * 10);
                Thread.Sleep(1000);
            }

        });

        // what to do when progress changed (update the progress bar for example)
        bw.ProgressChanged += new ProgressChangedEventHandler(
        delegate(object o, ProgressChangedEventArgs args)
        {
            label1.Text = string.Format("{0}% Completed", args.ProgressPercentage);
        });

        // what to do when worker completes its task (notify the user)
        bw.RunWorkerCompleted += new RunWorkerCompletedEventHandler(
        delegate(object o, RunWorkerCompletedEventArgs args)
        {
            label1.Text = "Finished!";
        });

        bw.RunWorkerAsync();
    }

Answer 1

but i do not understand what is the difference between calling any method with the help of thread class or ThreadPool class

The main difference is whether you manage the thread lifetime yourself (Thread), or you take advantage of the "pool" of threads the framework already creates.

Using ThreadPool.QueueUserWorkItem will (often) use a thread that already exists in the system. This means you don't have the overhead of spinning up a new thread - instead, a set of threads is already there, and your work is just run on one of them. This can be especially beneficial if you're doing many operations which are short lived.

When you use new Thread, you actually spin up a new thread that will live until your delegate completes its execution.

Note that, as of .NET 4 and 4.5, I'd recommend using the Task and Task<T> types instead of making your own threads, or using ThreadPool.QueueUserWorkItem. These (by default) use the thread pool to execute, but provide many other useful abstractions, especially with C# 5 and the await/async keywords.

now also tell me what is BackgroundWorker class and how it is different from Thread & ThreadPool class. h

The BackgroundWorker class is an abstraction over the thread pool. It uses the ThreadPool to queue up "work" (your DoWork event handler), but also provides extra functionality which allows progress and completion events to be posted back to the initial SynchronizationContext (which, in a GUI program, will typically be the user interface thread). This simplifies tasks where you want to update a UI for progress or completion notifications as background "work" is running on a background thread.