2

I was reading this question and answer by Hans but still I need a clarification.

AFAIK ,

The purpose of asynchronous methods is to allow many tasks to run on few threads; while the purpose of asynchronous delegates is to execute a task in parallel with the caller.

But regarding both asynchronous operations:

If the BeginInvoke returns immediately to the caller (and it does with Asynchronous delegate) , so there must be other thread which actually do the job and signal when it finished.

So what is the difference between using that thread to a regular threadpool thread ? And I answer : only the fact that those threadpool threads are already there and waiting to be run ?

But what about the fact that when BeginInvoke run and returned immediatly , someone else has actually do the dirty job ( and a code must be run under a thread which is under process.) so there must be somewhere a creation of thread (which run after beginXXX call)

What am I missing?

Community
  • 1
  • 1
Royi Namir
  • 144,742
  • 138
  • 468
  • 792
  • This may help: http://stackoverflow.com/questions/14961450/where-are-clr-defined-methods-like-delegate-begininvoke-documented – Alexey Raga Mar 12 '13 at 08:17

2 Answers2

2

Delegate.BeginInvoke uses a threadpool thread, just like QueueUserWorkItem. The difference is that it implements the APM pattern, which allows the caller to use a WaitHandle to wait for the call to finish, and also supply a callback.

The Begin/End method pair (AKA the Asynchronous Programming Model) can be found in many places, and it is entirely up to the implementer to decide what happens when you call 'begin'. In many cases, a IO completion port is used, which is a very efficient way for waiting for IO to complete. When IO completes, a threadpool thread is used to execute the callback, but it is taken from a different part of the threadpool (and that's why Set{Min,Max}Threads have two numbers.)

As a side note, with .NET 4.5 (and even 4.0) it is far easier to use Tasks for asynchrony. Many classes have been augmented with methods like 'XXXTaskAsyc' which return a Task object.

Eli Arbel
  • 22,391
  • 3
  • 45
  • 71
  • Eli : you said _When IO completes s, a threadpool thread is used to execute the callback_ but lets take one step back , **before it** completes and still working , is it working under a threadpool thread ? – Royi Namir Mar 12 '13 at 08:23
  • Eli so that is my actual question. Im yielding the work the an OS thread. so it is a creation of thread. so where is the benefit? just that it aint a threapool thread? – Royi Namir Mar 12 '13 at 08:42
1

It appears that you already got the answer yourself: BeginInvoke uses a Threadpool-thread to do the work. In the end, it appears to be not any different from queueing a work-item to the threadpool yourself. The only things is that is a higher level of abstraction you are facing. You are not actually concerned with queueing and providing a callback explicitly in your code.
This has already been looked at. See SO here for an idea.

Community
  • 1
  • 1
bash.d
  • 13,029
  • 3
  • 29
  • 42
  • _fetching a web page, for instance, might take up to several seconds from start to end (because of a potentially slow connection) and yet consume only a fraction of a millisecond of CPU time in total. Processing an HTTP request and response is not computationally intensive. This means that a server thread dedicated to processing a single client request might spend 99% of its time blocked_. **SO** are you telling me that still there will be a threadpool (thread) which is blocked 99% of time ? – Royi Namir Mar 12 '13 at 08:18
  • Why the entire threadpool? Of course a thread will block, if it waits for data or anything else. That doesn't block the entire threadpool, though. – bash.d Mar 12 '13 at 08:20
  • @RoyiNamir Okay, but still that is the nature of a thread waiting for input. And if it is meant to be blocked for a certain amount of time, than that will happen. – bash.d Mar 12 '13 at 08:26
  • @EliArbel these are special cases, of course. But if you do it the standard way, the thread will block. – bash.d Mar 12 '13 at 08:32