Long running delegates manager

[=?Utf-8?B?QWxwaGFwYWdl?=]

Hello,

I have a class MyWorker.
Each time I create a new instance of MyWorker, I queue it to the ThreadPool.
So, 1 MyWorker object is pooled and belongs to its thread (there can't have 2
MyWorker in 1 thread from the ThreadPool).
When MyWorker is initialized or instanciate, I use an asynchronous delegate
to execute a long running process (depending on users, the job can be
quicker). So, this async delegate will use or create a new thread from the
ThreadPool to execute.
The MyWorker thread must wait for this async delegate to complete,the async
delegate thread will free up and will return to the ThreadPool, finally the
MyWorker object is able to continue processing with the result of the async
delegate.
But that means each MyWorker use 2 threads during long running process: I
think my app is bad design and can be optimized.

To increase the scalability, I heard about a kind of long running delegates
manager. But I can't find such a tool: I only find "fire-and-forget"
delegate which will corrupt MyWorker object because it doesn't wait for the
async delegate to complete or the same process I describe and use.
I need help to build a robust code implementing those features:
- queue each MyWorker in the ThreadPool
- each time the async delegate of MyWorker is invoked, free the MyWorker
thread to let other MyWorker object or other async delegate use it
- after the async delegate is completed and the thread is free, continue and
finalize the MyWorker process. (I think the long running delegates manager
will run on the Main app thread)

Thanks in advance for your help.

[=?Utf-8?B?QWxwaGFwYWdl?=]

Thanks Pete, you are right.

I can run all the MyWorker code on one thread.
But the goal is to free threads to let other faster MyWorker object execute
on other threads. I think this part of my question was not clear, sorry.

Your comment helps me and I decide to use a custom ThreadPool to process the
long running jobs instead of an async delegate. But the problem remains:
I execute MyWorker on the framework ThreadPool, if a long running job is
required, I start a thread from my custom ThreadPool. But I don't know how
to free the current framework ThreadPool thread and at the same time waiting
for the custom ThreadPool thread (ie long running job) to complete.
So, I can run more fast MyWorker.

[Peter Duniho]

On Tue, 20 May 2008 09:28:02 -0700, Alphapage
<Al*******@disc ussions.microso ft.comwrote:

I can run all the MyWorker code on one thread.
But the goal is to free threads to let other faster MyWorker object
execute
on other threads. I think this part of my question was not clear, sorry.

It was clear you _think_ that's your goal. But so far, you haven't
written anything to support that idea.

You have very clearly stipulated that you have a thread that simply wants
to execute a delegate on a different thread, and while that delegate is
executing, the first thread should wait for the delegate to complete.

You have also very clearly stipulated that you want for the first thread
to give up its thread while the delegate is executing so that the thread
is available for other processing.

But: this is _exactly_ what happens if you simply call the delegate from
the first thread, without invoking it asynchronously.

Your comment helps me and I decide to use a custom ThreadPool to process
the
long running jobs instead of an async delegate.

There's nothing about the problem you've stated that argues in favor of a
custom ThreadPool.

But the problem remains:
I execute MyWorker on the framework ThreadPool, if a long running job is
required, I start a thread from my custom ThreadPool. But I don't know
how
to free the current framework ThreadPool thread and at the same time
waiting
for the custom ThreadPool thread (ie long running job) to complete.
So, I can run more fast MyWorker.

You cannot "free" a thread without simply having the code executing on
that thread return to the caller. In a thread pool, at the top of the
thread is a loop that sits and waits for delegates to execute. When a
delegate is queued to the thread pool, some thread picks up that delegate
and calls it. Until the delegate returns, that thread is committed to
executing the thread. You can't interrupt the delegate externally,
execute some other code on the same thread, and then resume the delegate.

However, what you _can_ do is simply have the first delegate call some
other delegate. This will do exactly what you're asking for: the original
delegate, queued to the thread pool, will be interrupted while the second
delegate is executing on the very same thread. When the second delegate
completes, control will return to the first delegate at which point it
will continue executing on the same thread it was always executing.

This is just how method calling works. You call a method, your own code
doesn't get control back until that method returns. All code runs on
_some_ thread, and any time some code calls a method, it's "interrupte d"
until the method it called returns, yielding use of the same thread to the
method that was called.

You are REALLY overthinking this problem. It's not nearly as complicated
as you seem bent on making it. :)

Pete