Thread Pool Deadlock -- need help! 
Author Message
 Thread Pool Deadlock -- need help!

My (possibly flawed) understanding:

a) ThreadPool typically allows only 25 tasks to be queued simultaneously.

b) In the event that 25 tasks are queued, attempts to add subsequent tasks
to the queue will block until the queue size falls below 25.

c) Ansynchronous calls (BeginInvoke()) use the thread pool.

My situation:

a) I want to perform 60 tasks asynchronously. I enter a for-loop which loops
60 times, calling BeginInvoke against a delegate each time. Lets call the
asynchronous function AsyncFunc().

b) AsyncFunc() itself also performs an operation which requires two
asynchronous database lookups to take place. AsyncFunc() therefore calls
BeginInvoke() on two different database lookup function delegates.

c) By the time AsyncFunc() gets around to performing its two async database
calls, the thread pool is locked at it's maximum 25 due to the queued async
tasks described in a).. When BeginInvoke() is called to kick off the
database lookup functionality, BeginInvoke() blocks forever because the
ThreadPool is at 25. This is of course a deadlock because the thread pool is
full of tasks which depend on the database lookup which can never launch.

I'm stumped. Any ideas on how to fix the deadlock without resorting to
making everything synchronous?

David



Sun, 28 Nov 2004 06:41:11 GMT  
 Thread Pool Deadlock -- need help!
David, I've run into similar issues.  A couple of possible work arounds I've
come up with are:
1. increase the size of the thread pool - this is really just a bandaid and
doesn't do anything besides extend the time until you see the deadlock
again.
2. Monitor the number of available worker pool threads and only send
requests when threads are available - defeats the point of being able to
queue work items.
3.  Create my own thread pool class so that I can have more than one thread
pool per process

I'm not particularly with any of these as a solution except maybe #3.
Another cause for concern is that many system processes use the same thread
pool.  For instance, if I wanted to use a thread pool in an ASP application
I would be competing with ASP for the thread pool since the ASP worker
threads come from that same pool.  If I got 25 requests to my ASP
application my app is in danger of deadlocking.

MSDN just released an article on thread pooling which I found helpful.
http://msdn.microsoft.com/library/?url=/library/en-us/dndotnet/html/p...
pool.asp?frame=true

Has anyone else come up with any particularly good solutions?

--
Greg
http://www.claritycon.com/

"Rev. Dr. Hulio Manuel Sanchez-Cruz, MCSD, PhD, MD, DDS, CPA, RN, Esq."

Quote:

> My (possibly flawed) understanding:

> a) ThreadPool typically allows only 25 tasks to be queued simultaneously.

> b) In the event that 25 tasks are queued, attempts to add subsequent tasks
> to the queue will block until the queue size falls below 25.

> c) Ansynchronous calls (BeginInvoke()) use the thread pool.

> My situation:

> a) I want to perform 60 tasks asynchronously. I enter a for-loop which
loops
> 60 times, calling BeginInvoke against a delegate each time. Lets call the
> asynchronous function AsyncFunc().

> b) AsyncFunc() itself also performs an operation which requires two
> asynchronous database lookups to take place. AsyncFunc() therefore calls
> BeginInvoke() on two different database lookup function delegates.

> c) By the time AsyncFunc() gets around to performing its two async
database
> calls, the thread pool is locked at it's maximum 25 due to the queued
async
> tasks described in a).. When BeginInvoke() is called to kick off the
> database lookup functionality, BeginInvoke() blocks forever because the
> ThreadPool is at 25. This is of course a deadlock because the thread pool
is
> full of tasks which depend on the database lookup which can never launch.

> I'm stumped. Any ideas on how to fix the deadlock without resorting to
> making everything synchronous?

> David



Sun, 28 Nov 2004 12:22:02 GMT  
 Thread Pool Deadlock -- need help!
I think the problem in you code is that you wait for the async databasecall
inside you asyncfunc.

Use sync calls to the database inside your async functions if you want an
answer from them.

A recent document about ThreadPools in MSDN tells you about that.

/Patrik

"Rev. Dr. Hulio Manuel Sanchez-Cruz, MCSD, PhD, MD, DDS, CPA, RN, Esq."

Quote:

> My (possibly flawed) understanding:

> a) ThreadPool typically allows only 25 tasks to be queued simultaneously.

> b) In the event that 25 tasks are queued, attempts to add subsequent tasks
> to the queue will block until the queue size falls below 25.

> c) Ansynchronous calls (BeginInvoke()) use the thread pool.

> My situation:

> a) I want to perform 60 tasks asynchronously. I enter a for-loop which
loops
> 60 times, calling BeginInvoke against a delegate each time. Lets call the
> asynchronous function AsyncFunc().

> b) AsyncFunc() itself also performs an operation which requires two
> asynchronous database lookups to take place. AsyncFunc() therefore calls
> BeginInvoke() on two different database lookup function delegates.

> c) By the time AsyncFunc() gets around to performing its two async
database
> calls, the thread pool is locked at it's maximum 25 due to the queued
async
> tasks described in a).. When BeginInvoke() is called to kick off the
> database lookup functionality, BeginInvoke() blocks forever because the
> ThreadPool is at 25. This is of course a deadlock because the thread pool
is
> full of tasks which depend on the database lookup which can never launch.

> I'm stumped. Any ideas on how to fix the deadlock without resorting to
> making everything synchronous?

> David



Sun, 28 Nov 2004 20:47:48 GMT  
 Thread Pool Deadlock -- need help!
thanks guys... looks like I've got some reading an experimentation to do...


Sun, 28 Nov 2004 22:51:47 GMT  
 Thread Pool Deadlock -- need help!
Patrick, what happens though if you write an Async function which uses a
thread pool and the Socket class for instance?  The socket class uses the
ThreadPool internally and therefore is 'competing' with your async function.
The problem isn't unique to the socket class.  This could happen with any
class which uses the ThreadPool internally if it is called from another
class which uses the threadpool.  So what you are saying is if you are
writing an ASP.Net app (worker threads in ThreadPool) you can't use the
Async Socket functions (uses ThreadPool)?  That scenario (among others)
would put you at risk for a deadlock.  This seems like a real problem with
the async functions and using the thread pool.  It just seems like if you
use the ThreadPool you are limited as to the classes you can use within your
thread functions.

--
Greg
http://www.claritycon.com/


Quote:
> I think the problem in you code is that you wait for the async
databasecall
> inside you asyncfunc.

> Use sync calls to the database inside your async functions if you want an
> answer from them.

> A recent document about ThreadPools in MSDN tells you about that.

> /Patrik

> "Rev. Dr. Hulio Manuel Sanchez-Cruz, MCSD, PhD, MD, DDS, CPA, RN, Esq."

> > My (possibly flawed) understanding:

> > a) ThreadPool typically allows only 25 tasks to be queued
simultaneously.

> > b) In the event that 25 tasks are queued, attempts to add subsequent
tasks
> > to the queue will block until the queue size falls below 25.

> > c) Ansynchronous calls (BeginInvoke()) use the thread pool.

> > My situation:

> > a) I want to perform 60 tasks asynchronously. I enter a for-loop which
> loops
> > 60 times, calling BeginInvoke against a delegate each time. Lets call
the
> > asynchronous function AsyncFunc().

> > b) AsyncFunc() itself also performs an operation which requires two
> > asynchronous database lookups to take place. AsyncFunc() therefore calls
> > BeginInvoke() on two different database lookup function delegates.

> > c) By the time AsyncFunc() gets around to performing its two async
> database
> > calls, the thread pool is locked at it's maximum 25 due to the queued
> async
> > tasks described in a).. When BeginInvoke() is called to kick off the
> > database lookup functionality, BeginInvoke() blocks forever because the
> > ThreadPool is at 25. This is of course a deadlock because the thread
pool
> is
> > full of tasks which depend on the database lookup which can never
launch.

> > I'm stumped. Any ideas on how to fix the deadlock without resorting to
> > making everything synchronous?

> > David



Sun, 28 Nov 2004 23:20:02 GMT  
 Thread Pool Deadlock -- need help!
    This seems to be the case. After reading the MSDN article refered to in
this newsgroup thread, the golden rule (in the section on deadlocking) is:

"Do not create any class whose synchronous methods wait for asynchronous
functions, since this class could be called from a thread on the pool"

    This makes the thread pool virtually useless. You can't use it in
ASP.NET applications (as you pointed out), remoted objects (whose methods
are called via the thread pool) or virtually any other common server-based
app scenario. I wish I would have understood this before I wasted so much of
my time writing anync code which makes of the thread pool.

    Once the load on your server app increases, you're virtually guaranteed
to get a thread-pool deadlock. That sucks.

David



Sun, 28 Nov 2004 23:56:40 GMT  
 Thread Pool Deadlock -- need help!
Yes, ASP.NET holds on to CompletionPorts and uses the ThreadPool that way.

I think you should run any code using the threadpool on a separate process
(like a windows service) and not inside your ASP.NET app. And it actually
makes sense to move any heavy processing or long running code away from
ASP.NET into a separate process (or separate machine) to let ASP.NET do its
job of rendering HTML.

/Patrik


Quote:
> Patrick, what happens though if you write an Async function which uses a
> thread pool and the Socket class for instance?  The socket class uses the
> ThreadPool internally and therefore is 'competing' with your async
function.
> The problem isn't unique to the socket class.  This could happen with any
> class which uses the ThreadPool internally if it is called from another
> class which uses the threadpool.  So what you are saying is if you are
> writing an ASP.Net app (worker threads in ThreadPool) you can't use the
> Async Socket functions (uses ThreadPool)?  That scenario (among others)
> would put you at risk for a deadlock.  This seems like a real problem with
> the async functions and using the thread pool.  It just seems like if you
> use the ThreadPool you are limited as to the classes you can use within
your
> thread functions.

> --
> Greg
> http://www.claritycon.com/


message

> > I think the problem in you code is that you wait for the async
> databasecall
> > inside you asyncfunc.

> > Use sync calls to the database inside your async functions if you want
an
> > answer from them.

> > A recent document about ThreadPools in MSDN tells you about that.

> > /Patrik

> > "Rev. Dr. Hulio Manuel Sanchez-Cruz, MCSD, PhD, MD, DDS, CPA, RN, Esq."



- Show quoted text -

Quote:
> > > My (possibly flawed) understanding:

> > > a) ThreadPool typically allows only 25 tasks to be queued
> simultaneously.

> > > b) In the event that 25 tasks are queued, attempts to add subsequent
> tasks
> > > to the queue will block until the queue size falls below 25.

> > > c) Ansynchronous calls (BeginInvoke()) use the thread pool.

> > > My situation:

> > > a) I want to perform 60 tasks asynchronously. I enter a for-loop which
> > loops
> > > 60 times, calling BeginInvoke against a delegate each time. Lets call
> the
> > > asynchronous function AsyncFunc().

> > > b) AsyncFunc() itself also performs an operation which requires two
> > > asynchronous database lookups to take place. AsyncFunc() therefore
calls
> > > BeginInvoke() on two different database lookup function delegates.

> > > c) By the time AsyncFunc() gets around to performing its two async
> > database
> > > calls, the thread pool is locked at it's maximum 25 due to the queued
> > async
> > > tasks described in a).. When BeginInvoke() is called to kick off the
> > > database lookup functionality, BeginInvoke() blocks forever because
the
> > > ThreadPool is at 25. This is of course a deadlock because the thread
> pool
> > is
> > > full of tasks which depend on the database lookup which can never
> launch.

> > > I'm stumped. Any ideas on how to fix the deadlock without resorting to
> > > making everything synchronous?

> > > David



Mon, 29 Nov 2004 00:22:49 GMT  
 Thread Pool Deadlock -- need help!
No, its makes sense that a thread that is already async shouldn't try to
implement it again. After all, there is no benefit of async times 2, it's
still just async.

/Patrik

"Rev. Dr. Hulio Manuel Sanchez-Cruz, MCSD, PhD, MD, DDS, CPA, RN, Esq."

Quote:

>     This seems to be the case. After reading the MSDN article refered to
in
> this newsgroup thread, the golden rule (in the section on deadlocking) is:

> "Do not create any class whose synchronous methods wait for asynchronous
> functions, since this class could be called from a thread on the pool"

>     This makes the thread pool virtually useless. You can't use it in
> ASP.NET applications (as you pointed out), remoted objects (whose methods
> are called via the thread pool) or virtually any other common server-based
> app scenario. I wish I would have understood this before I wasted so much
of
> my time writing anync code which makes of the thread pool.

>     Once the load on your server app increases, you're virtually
guaranteed
> to get a thread-pool deadlock. That sucks.

> David



Mon, 29 Nov 2004 00:37:34 GMT  
 Thread Pool Deadlock -- need help!

Quote:
> No, its makes sense that a thread that is already async shouldn't try to
> implement it again. After all, there is no benefit of async times 2, it's
> still just async.

> /Patrik

    I'm pretty new at this, so I'm not claiming your wrong, but I can think
of lots of times when it makes sense to have nested asyncs. For example:

    You've got a windows service that exposes itself as a remoted object. It
exposes a single function called DoSomething() which could be called by
multiple clients simultaneously. Clearly each call to DoSomething() is
called by the .NET runtime on an async thread-pool thread [the documentation
says that this is the case.]... Now, in order for DoSomething() to do its
work, it must call FindSomethingA() and FindSomethingB()... These two lookup
functions each have a two second delay while talking to the database and are
totally independent of one another so it makes sense to do them
asynchronously, correct? So now you've got an async call nested within
another. Everything will work just fine 99.99% of the time... until
DoSomething() is called by lots of clients at once and the thread-pool
deadlocks.

    I think I'm going to take Greg's advice... I'll just check the number of
threads available in the thread pool prior to my BeginInvoke() call. I'm
thinking that if there are no threads available, I'll throw a "Server is
busy" exception instead of calling BeginInvoke().

David



Mon, 29 Nov 2004 01:09:45 GMT  
 Thread Pool Deadlock -- need help!
I could wery well be wrong about this. :-)

But this is how I'm thinking.

In your example (if the databases are on separate machines) you would be
able to execute one DoSomething() in about half the time, right??? And as
more clients hits DoSomething() eventually the threadpool (outer async) will
do its work and queue the jobs up for you depending on your average
systemload.

But by executing two new threads INSIDE the outer thread you will now have
three threads running instead of one (the first one can't finish befor the
two have finished) for each client. That makes, at a maximum of the default
25 active in a pool, a total of 75 active threads in the process. And if you
run you app on a 4 proc server yo will have a total of 300 active threads.
Now the context-switching between your active threads starts to affect your
system. And what if you have 10 programs running on your system doing
this??? 3000 threads....

I belive that the whole purpouse of the threadpool is to limit the active
threads and their impact on the system, not to give you multitasking or a
jobqueue.

/Patrik

"Rev. Dr. Hulio Manuel Sanchez-Cruz, MCSD, PhD, MD, DDS, CPA, RN, Esq."

Quote:
> > No, its makes sense that a thread that is already async shouldn't try to
> > implement it again. After all, there is no benefit of async times 2,
it's
> > still just async.

> > /Patrik

>     I'm pretty new at this, so I'm not claiming your wrong, but I can
think
> of lots of times when it makes sense to have nested asyncs. For example:

>     You've got a windows service that exposes itself as a remoted object.
It
> exposes a single function called DoSomething() which could be called by
> multiple clients simultaneously. Clearly each call to DoSomething() is
> called by the .NET runtime on an async thread-pool thread [the
documentation
> says that this is the case.]... Now, in order for DoSomething() to do its
> work, it must call FindSomethingA() and FindSomethingB()... These two
lookup
> functions each have a two second delay while talking to the database and
are
> totally independent of one another so it makes sense to do them
> asynchronously, correct? So now you've got an async call nested within
> another. Everything will work just fine 99.99% of the time... until
> DoSomething() is called by lots of clients at once and the thread-pool
> deadlocks.

>     I think I'm going to take Greg's advice... I'll just check the number
of
> threads available in the thread pool prior to my BeginInvoke() call. I'm
> thinking that if there are no threads available, I'll throw a "Server is
> busy" exception instead of calling BeginInvoke().

> David



Mon, 29 Nov 2004 03:59:09 GMT  
 Thread Pool Deadlock -- need help!

Quote:

> I could wery well be wrong about this. :-)
> But this is how I'm thinking.

> In your example (if the databases are on separate machines) you would be
> able to execute one DoSomething() in about half the time, right??? And as
> more clients hits DoSomething() eventually the threadpool (outer async) will
> do its work and queue the jobs up for you depending on your average
> systemload.

> But by executing two new threads INSIDE the outer thread you will now have
> three threads running instead of one (the first one can't finish befor the
> two have finished) for each client. That makes, at a maximum of the default
> 25 active in a pool, a total of 75 active threads in the process. And if you
> run you app on a 4 proc server yo will have a total of 300 active threads.
> Now the context-switching between your active threads starts to affect your
> system. And what if you have 10 programs running on your system doing
> this??? 3000 threads....

    this shouldn't be a problem. My Win2k server (dual proc box) has 870 threads
    running, doing nothing but running exchange and sqlserver.

    afaik, the routines executed are asynchronous, so once called, will spawn
    new threads and will then or sleep and wait for a call to the callback, or
    die. (implemented correctly). MSDN had a nice threadpool article a couple
    of days ago.

Quote:
> I belive that the whole purpouse of the threadpool is to limit the active
> threads and their impact on the system, not to give you multitasking or a
> jobqueue.

    somewhat yes. Instead of measuring the balance between CPU hogging and
    context switching yourself, the threadpool does that for you.

    Most people however create more problems than they resolve when they
    include multi-threading into their programs. The threadpool is easy to
    use, however still, multi-threading is a complex ballgame that's more
    than just spawning threadobjects. (unfortunately)

        FB

- Show quoted text -

Quote:

> /Patrik

> "Rev. Dr. Hulio Manuel Sanchez-Cruz, MCSD, PhD, MD, DDS, CPA, RN, Esq."

> > > No, its makes sense that a thread that is already async shouldn't try to
> > > implement it again. After all, there is no benefit of async times 2,
> it's
> > > still just async.

> > > /Patrik

> >     I'm pretty new at this, so I'm not claiming your wrong, but I can
> think
> > of lots of times when it makes sense to have nested asyncs. For example:

> >     You've got a windows service that exposes itself as a remoted object.
> It
> > exposes a single function called DoSomething() which could be called by
> > multiple clients simultaneously. Clearly each call to DoSomething() is
> > called by the .NET runtime on an async thread-pool thread [the
> documentation
> > says that this is the case.]... Now, in order for DoSomething() to do its
> > work, it must call FindSomethingA() and FindSomethingB()... These two
> lookup
> > functions each have a two second delay while talking to the database and
> are
> > totally independent of one another so it makes sense to do them
> > asynchronously, correct? So now you've got an async call nested within
> > another. Everything will work just fine 99.99% of the time... until
> > DoSomething() is called by lots of clients at once and the thread-pool
> > deadlocks.

> >     I think I'm going to take Greg's advice... I'll just check the number
> of
> > threads available in the thread pool prior to my BeginInvoke() call. I'm
> > thinking that if there are no threads available, I'll throw a "Server is
> > busy" exception instead of calling BeginInvoke().

> > David



Mon, 29 Nov 2004 04:12:39 GMT  
 Thread Pool Deadlock -- need help!

Quote:
> Now the context-switching between your active threads starts to affect
your
> system.

    Yes, I guess that's really the crux of the whole matter. Let me ask you
this:

    If I have 3000 threads *running*, context-switching is a huge problem,
but what if (on a 4 CPU machine), I have 3000 existing threads, but only 4
of them are running. The rest of the threads are in a "wait state" --
waiting for completion of some async activity... what are the
context-switching ramifications of this? Does context-switching still come
into play here for the waiting threads? clearly it comes into play to SOME
extent, since each thread needs to periodically check to see if it should
stop waiting... but I wonder how much context-switching overhead would
really exist here.



Mon, 29 Nov 2004 04:10:59 GMT  
 Thread Pool Deadlock -- need help!
I think that as long as you have threads created, they participate in
contextswithing, even if they are marked as in wait-state. Thats why a
threadpool can make an big difference in a application. I remember that I
read an article about this somewhere (on MSDN) but I cant find it again. It
would be nice if someone (MS???) could test this on different hardware and
different load to see how it affects performance.

/Patrik

"Rev. Dr. Hulio Manuel Sanchez-Cruz, MCSD, PhD, MD, DDS, CPA, RN, Esq."

Quote:

> > Now the context-switching between your active threads starts to affect
> your
> > system.

>     Yes, I guess that's really the crux of the whole matter. Let me ask
you
> this:

>     If I have 3000 threads *running*, context-switching is a huge problem,
> but what if (on a 4 CPU machine), I have 3000 existing threads, but only 4
> of them are running. The rest of the threads are in a "wait state" --
> waiting for completion of some async activity... what are the
> context-switching ramifications of this? Does context-switching still come
> into play here for the waiting threads? clearly it comes into play to SOME
> extent, since each thread needs to periodically check to see if it should
> stop waiting... but I wonder how much context-switching overhead would
> really exist here.



Tue, 30 Nov 2004 18:10:05 GMT  
 Thread Pool Deadlock -- need help!



Quote:
> > I could wery well be wrong about this. :-)
> > But this is how I'm thinking.

> > In your example (if the databases are on separate machines) you would be
> > able to execute one DoSomething() in about half the time, right??? And
as
> > more clients hits DoSomething() eventually the threadpool (outer async)
will
> > do its work and queue the jobs up for you depending on your average
> > systemload.

> > But by executing two new threads INSIDE the outer thread you will now
have
> > three threads running instead of one (the first one can't finish befor
the
> > two have finished) for each client. That makes, at a maximum of the
default
> > 25 active in a pool, a total of 75 active threads in the process. And if
you
> > run you app on a 4 proc server yo will have a total of 300 active
threads.
> > Now the context-switching between your active threads starts to affect
your
> > system. And what if you have 10 programs running on your system doing
> > this??? 3000 threads....

>     this shouldn't be a problem. My Win2k server (dual proc box) has 870
threads
>     running, doing nothing but running exchange and sqlserver.

>     afaik, the routines executed are asynchronous, so once called, will
spawn
>     new threads and will then or sleep and wait for a call to the
callback, or
>     die. (implemented correctly). MSDN had a nice threadpool article a
couple
>     of days ago.

I think that even if the thread is asleep or in waitstate, it is part of
contextswitching. That makes a difference if you have enough threads
created. Would be nice to see a test on this...

/Patrik

- Show quoted text -

Quote:

> > I belive that the whole purpouse of the threadpool is to limit the
active
> > threads and their impact on the system, not to give you multitasking or
a
> > jobqueue.

>     somewhat yes. Instead of measuring the balance between CPU hogging and
>     context switching yourself, the threadpool does that for you.

>     Most people however create more problems than they resolve when they
>     include multi-threading into their programs. The threadpool is easy to
>     use, however still, multi-threading is a complex ballgame that's more
>     than just spawning threadobjects. (unfortunately)

>         FB

> > /Patrik

> > "Rev. Dr. Hulio Manuel Sanchez-Cruz, MCSD, PhD, MD, DDS, CPA, RN, Esq."



- Show quoted text -

Quote:
> > > > No, its makes sense that a thread that is already async shouldn't
try to
> > > > implement it again. After all, there is no benefit of async times 2,
> > it's
> > > > still just async.

> > > > /Patrik

> > >     I'm pretty new at this, so I'm not claiming your wrong, but I can
> > think
> > > of lots of times when it makes sense to have nested asyncs. For
example:

> > >     You've got a windows service that exposes itself as a remoted
object.
> > It
> > > exposes a single function called DoSomething() which could be called
by
> > > multiple clients simultaneously. Clearly each call to DoSomething() is
> > > called by the .NET runtime on an async thread-pool thread [the
> > documentation
> > > says that this is the case.]... Now, in order for DoSomething() to do
its
> > > work, it must call FindSomethingA() and FindSomethingB()... These two
> > lookup
> > > functions each have a two second delay while talking to the database
and
> > are
> > > totally independent of one another so it makes sense to do them
> > > asynchronously, correct? So now you've got an async call nested within
> > > another. Everything will work just fine 99.99% of the time... until
> > > DoSomething() is called by lots of clients at once and the thread-pool
> > > deadlocks.

> > >     I think I'm going to take Greg's advice... I'll just check the
number
> > of
> > > threads available in the thread pool prior to my BeginInvoke() call.
I'm
> > > thinking that if there are no threads available, I'll throw a "Server
is
> > > busy" exception instead of calling BeginInvoke().

> > > David



Tue, 30 Nov 2004 18:16:46 GMT  
 Thread Pool Deadlock -- need help!
Hello!

I don't know the exact number of threads that are maintained in the pool,
but yes, you are right, they are small in number and when busy, subsequent
requests are blocked until a pool thread is free.

I suggest that after subjecting couple of your threads to the pool, you can
try to individually spawn a thread for additional requests.

However, with even 25 threads in the pool being used (as you quoted in your
post), its quite a load for a un-processor system.

--

"French is the language of love, C# is for everything else...."
Kumar Gaurav Khanna
MCSE (Windows 2000), MCSE NT 4.0, MCP+I
WWW: http://www.wintoolzone.com/

"Rev. Dr. Hulio Manuel Sanchez-Cruz, MCSD, PhD, MD, DDS, CPA, RN, Esq."

Quote:

> My (possibly flawed) understanding:

> a) ThreadPool typically allows only 25 tasks to be queued simultaneously.

> b) In the event that 25 tasks are queued, attempts to add subsequent tasks
> to the queue will block until the queue size falls below 25.

> c) Ansynchronous calls (BeginInvoke()) use the thread pool.

> My situation:

> a) I want to perform 60 tasks asynchronously. I enter a for-loop which
loops
> 60 times, calling BeginInvoke against a delegate each time. Lets call the
> asynchronous function AsyncFunc().

> b) AsyncFunc() itself also performs an operation which requires two
> asynchronous database lookups to take place. AsyncFunc() therefore calls
> BeginInvoke() on two different database lookup function delegates.

> c) By the time AsyncFunc() gets around to performing its two async
database
> calls, the thread pool is locked at it's maximum 25 due to the queued
async
> tasks described in a).. When BeginInvoke() is called to kick off the
> database lookup functionality, BeginInvoke() blocks forever because the
> ThreadPool is at 25. This is of course a deadlock because the thread pool
is
> full of tasks which depend on the database lookup which can never launch.

> I'm stumped. Any ideas on how to fix the deadlock without resorting to
> making everything synchronous?

> David



Wed, 08 Dec 2004 11:46:35 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. Help: Multi-thread, thread pool, or asynchronous socket

2. Multi-thread, thread pool, or asynchronous socket

3. Aborting the threads operated by the thread pool

4. Changing the amount of available threads in thread pool

5. Thread pools and COM (HELP)

6. Timeouts and suspected thread deadlocks

7. Deadlock on thread exit using TRACE() on W2K

8. Deadlocks caused by OutputDebugString / TRACE near thread exit

9. Deadlock on thread exit using TRACE() on W2K

10. Deadlock with std::map and free threaded COM

11. Thread pooling

12. thread pool

 

 
Powered by phpBB® Forum Software