Asynchronous Execution and Thread Pool in a Server Scenario

[dsitton]

I've read several posts about his issue but could not understand what
exactly going on under the hood.

In a server scenario, a Thread Pool thread is processing a request. At
some point it needs to do an IO call (database, web service, file
system etc). Basically, I have two choices:
1. Synchronously. This will block the Thread Pool thread which is not a
good thing since this thread could be doing something else (process
other requests for example)
2. Asynchronously. The thread that currently executes the request will
return to the thread pool and another one will continue the work once
the callback is called. What I don't understand is, doesn't some
thread in the system needs to be waiting for a response anyway? Is this
going to be a thread outside the framework (which is just what I want)
or just another thread from the thread pool? Does this change from one
IO target to the other? How can I tell?

It is important for me to know since if it is just another thread from
the thread pool, I might be better off with option #1 since the code is
cleaner and it has the same affect.

Thanks,
Daniel

 

[Guest]

Pools are not stuck on a single number of items unless you throttle them (not
exactly true, as you can reach limits: memory, CPU, etc.). If you call for a
thread from a thread pool, you are not going to block other items unless you
are using an enormous amount of threads across all users. If you really have
this type of traffic, it means you are doing a huge amount of business, which
I consider a success problem (ie, you can afford to buy a new server and
create a web/application farm).

The decision for asynch is one of needing parallel processes rather than
serial. IE, I can calculate tax while I figure shipping, so I will do each on
its own thread. The breakdown point is when each parallel process only takes
a fraction of a second. The second criteria for asynch is one of need
(relating to the last part of the last sentence). IE, only if running
processes in serial is causing a user problem. If you get 10 processes done
in a second and two or three seconds is acceptable, asynch may be overkill.

To your question, as I understand it. Does a single thread wait until it is
finished before being released to the pool? Yes. Does this block other
requests waiting for threads? Only if the pool is empty and unable to create
additional threads. If condition 1 and 2 are true, you most likely have an
architecture problem, a success problem (back to last paragraph) or an
improperly "throttled" pool.

To understand more, consider this. A CPU can only process one thread at any
one time. But, it processes very quickly and can "multi-process" by giving
slices of time to different processes (to appear to run multiple processes at
the same time). In reality, every blip is consumed by one thread and one
thread only (hyperthreading sort of breaks the rule). With asynch, there is
an appearance of multiple threads running at once, but, in reality, the OS
and CPU are slicing time.

Short story: If you need asynch, use it. But, base the decision on need, not
want. If the entire process is taking too much time and some work can be done
in parallel, you have a great call for asynch.

---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************