473,324 Members | 2,214 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,324 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 1569
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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
by: Marina | last post by:
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...
5
by: Marina | last post by:
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...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

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.