Calling BeginInvoke on delegates and thread reusage

[Marina]

Hi, we have an app, that executes jobs submitted from an outside
application. It executes them asynchronusly, by creating a delegate to the
method that can run the job, and calling BeginInvoke on the method.

Throughout the job itself, we use the CallContext class to store information
that is needed by many classes in the call stream. This works well, and
concurrent threads are working fine.

What happens is, that after a job is done, and another one is started,
sometimes, the new job, is being executed on the same thread as the job that
just finished (i.e., they have the same thread id). So it looks like
threads are being reused by subsequent jobs - and so the information on the
CallContext is left over from the previous job (which has completed) - as
opposed to being cleared out.

Anyone know why the threads are being reused (especially without being
cleared out first) in this way?

 

[Jon Skeet [C# MVP]]

Hi, we have an app, that executes jobs submitted from an outside
application. It executes them asynchronusly, by creating a delegate to the
method that can run the job, and calling BeginInvoke on the method.

Throughout the job itself, we use the CallContext class to store information
that is needed by many classes in the call stream. This works well, and
concurrent threads are working fine.

What happens is, that after a job is done, and another one is started,
sometimes, the new job, is being executed on the same thread as the job that
just finished (i.e., they have the same thread id). So it looks like
threads are being reused by subsequent jobs - and so the information on the
CallContext is left over from the previous job (which has completed) - as
opposed to being cleared out.

Anyone know why the threads are being reused (especially without being
cleared out first) in this way?

I don't know about the clearing bit, but threads are reused because
BeginInvoke uses the ThreadPool. This is usually a very good thing, as
creating threads is a relatively expensive task.

 

[Mike V]

The problem with using the threadpool (that I've run into) is that if your
asynchronous delegate functions block, you basically lose a threadpool
thread and there's no way to kill it, as far as I know. If there is, please
let me know!

I realize that I shouldn't be calling functions that have the potential for
blocking forever, but these blocking calls are happening inside an API that
I have no control over.

 

[Marina]

Ok, thanks, that has shed some light onto the issue.

If creating an instance of the Thread class, and starting up a new thread
that way, would the same issue apply?

 

[John Saunders]

The problem with using the threadpool (that I've run into) is that if your
asynchronous delegate functions block, you basically lose a threadpool
thread and there's no way to kill it, as far as I know. If there is, please
let me know!

I realize that I shouldn't be calling functions that have the potential for
blocking forever, but these blocking calls are happening inside an API that
I have no control over.

Then this would be a good reason not to call that API from a thread pool
thread, wouldn't it?
--
John Saunders
John.Saunders at SurfControl.com

to

the

job

that

on

 

[Mike V]

Yes, which is exactly why I have to rewrite many lines of code to use
Threading.Threads instead of asynchronous delegates. Asynchronous delegates
are much more convenient for parameter passing and returning values.

The problem with using the threadpool (that I've run into) is that if your
asynchronous delegate functions block, you basically lose a threadpool
thread and there's no way to kill it, as far as I know. If there is, please
let me know!

I realize that I shouldn't be calling functions that have the potential for
blocking forever, but these blocking calls are happening inside an API that
I have no control over.

Then this would be a good reason not to call that API from a thread pool
thread, wouldn't it?