471,107 Members | 1,757 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,107 software developers and data experts.

Calling BeginInvoke on delegates and thread reusage

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?
Nov 22 '05 #1
10 1475
Marina <so*****@nospam.com> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 22 '05 #2
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.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Marina <so*****@nospam.com> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 22 '05 #3
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?

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Marina <so*****@nospam.com> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 22 '05 #4
Marina <so*****@nospam.com> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 22 '05 #5
"Mike V" <a-mikeva@microsoft dawt com> wrote in message
news:e4**************@TK2MSFTNGP12.phx.gbl...
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
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Marina <so*****@nospam.com> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too


Nov 22 '05 #6
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.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Marina <so*****@nospam.com> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 22 '05 #7
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?

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Marina <so*****@nospam.com> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 22 '05 #8
"Mike V" <a-mikeva@microsoft dawt com> wrote in message
news:e4**************@TK2MSFTNGP12.phx.gbl...
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
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Marina <so*****@nospam.com> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too


Nov 22 '05 #9
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.

"John Saunders" <john.saunders at SurfControl.com> wrote in message
news:#v**************@tk2msftngp13.phx.gbl...
"Mike V" <a-mikeva@microsoft dawt com> wrote in message
news:e4**************@TK2MSFTNGP12.phx.gbl...
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
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Marina <so*****@nospam.com> wrote:
> 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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too



Nov 22 '05 #10
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.

"John Saunders" <john.saunders at SurfControl.com> wrote in message
news:#v**************@tk2msftngp13.phx.gbl...
"Mike V" <a-mikeva@microsoft dawt com> wrote in message
news:e4**************@TK2MSFTNGP12.phx.gbl...
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
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Marina <so*****@nospam.com> wrote:
> 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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too



Nov 22 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.