Home/ Questions/Q 3331804
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T23:37:18+00:00

This is in reference to an article ‘ Simplify Asynchronous programming with Tasks ‘

  • 0

This is in reference to an article ‘Simplify Asynchronous programming with Tasks‘ published in MSDN magazine September 2010.

In this article the author put forth the problem of downloading a file using WebClient from a web page using HTTP.

The author explains that one way to solve the problem of a long running process which freezes the UI thread, is by creating a thread from thread pool and making it run a separate thread. The author explains that this is not a good solution because as more processes run, the thread pool ends up creating more threads which affects performance.

The author goes on to explain that another strategy to solve the problem is to create an event-based application. WebClient does implement asynchronous operations via the event-based pattern. I am with the author so far.

He then explains ‘This implementation resolves problem one of the inefficient thread based solution: unnecessary blocking of thread. The call to async returns immediately and does not block either the UI thread or a thread-pool thread. The process executes in the background‘.

What exactly is meant by the word ‘background‘ here? How is it different from thread?
Thanks

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    “Background” in this context is a Thread specifically created to handle the blocking task. It isn’t any different from a ThreadPool Thread except for the fact that it isn’t part of the pool.

    Use of the ThreadPool is avoided because it can only allocate a limited number of threads (MSDN defines this as 250 worker threads per processor, and 1000 I/O completion threads). This limitation is why it is acceptable to make a few blocking calls on ThreadPool threads, but if you make a lot of blocking calls from the pool it will reach a point where the job queue for the ThreadPool starts backing up due to the lack of available workers and performance becomes degraded. You can also increase the number of available Threads in the ThreadPool, but this comes with it’s own performance penalty, as each Thread has it’s own stack space allocated from memory.

    For those reading, the article Nair mentions is located here: http://msdn.microsoft.com/en-us/magazine/ff959203.aspx

    • 0