background worker in vb.net 2005

[Jesse Aufiero]

I'm wondering what the rule is on how to assure that the background worker
'DoWork' routine is truly running entirely in the background. My DoWork
routine calls another procedure which resides in a shared class. This other
procedure has local variables but also refrences class level variables. I'm
wondering if this might cause the DoWork routine to have to reach out to the
primary thread, thus greatly slowing down the routine.

How can I assure the routine is truly running entirely in the background,
and not having to reach over to the primary thread for any reason?

Thanks!

[Armin Zingler]

"Jesse Aufiero" <ja******@moaboil.comschrieb

I'm wondering what the rule is on how to assure that the background
worker 'DoWork' routine is truly running entirely in the background.
My DoWork routine calls another procedure which resides in a shared
class. This other procedure has local variables but also refrences
class level variables. I'm wondering if this might cause the DoWork
routine to have to reach out to the primary thread, thus greatly
slowing down the routine.

How can I assure the routine is truly running entirely in the
background, and not having to reach over to the primary thread for
any reason?

Thanks!

What does "reach over" mean? If you access/modify the same data on both
threads, you have to implement a synchronization mechanism, but that's
always true with multi threaded applications.
Armin

[Phill W.]

Jesse Aufiero wrote:

I'm wondering what the rule is on how to assure that the background worker
'DoWork' routine is truly running entirely in the background. My DoWork
routine calls another procedure which resides in a shared class. This other
procedure has local variables but also refrences class level variables. I'm
wondering if this might cause the DoWork routine to have to reach out to the
primary thread, thus greatly slowing down the routine.

How can I assure the routine is truly running entirely in the background,
and not having to reach over to the primary thread for any reason?

Copy the "worker" class/method out into a [new] Console Application and
call the "DoWork" method from Sub Main.

If this console app. compiles cleanly then your "worker" is nicely
self-contained.
If not, then it'll complain about all the stuff that it needs to "reach
back" into the enclosing class for, opening you up to contention problems.

HTH,
Phill W.

[Jesse Aufiero]

if i ported everything out, i'm sure it would run just fine, but when placed
back into the solution, i'm uneasy about how a shared function or sub in a
class is handled by the background process. might it reach out to the
primary thread in this case? not sure how to test this.
"Phill W." <p-.-a-.-w-a-r-d-@-o-p-e-n-.-a-c-.-u-kwrote in message
news:f6**********@south.jnrs.ja.net...

Jesse Aufiero wrote:

>I'm wondering what the rule is on how to assure that the background
worker 'DoWork' routine is truly running entirely in the background. My
DoWork routine calls another procedure which resides in a shared class.
This other procedure has local variables but also refrences class level
variables. I'm wondering if this might cause the DoWork routine to have
to reach out to the primary thread, thus greatly slowing down the
routine.

How can I assure the routine is truly running entirely in the background,
and not having to reach over to the primary thread for any reason?

Copy the "worker" class/method out into a [new] Console Application and
call the "DoWork" method from Sub Main.

If this console app. compiles cleanly then your "worker" is nicely
self-contained.
If not, then it'll complain about all the stuff that it needs to "reach
back" into the enclosing class for, opening you up to contention problems.

HTH,
Phill W.

[Phill W.]

Jesse Aufiero wrote:

if i ported everything out, i'm sure it would run just fine, but when placed
back into the solution, i'm uneasy about how a shared function or sub in a
class is handled by the background process. might it reach out to the
primary thread in this case? not sure how to test this.

I think what I meant was that you /shouldn't/ "port everything out".

The "worker" method should be as self-contained as you can make it.
Anything /else/ that you have to copy across to get it to compile and/or
work is something you need to worry about, i.e. either you have to
eliminate the need for it, by giving the worker more information up
front or you have to add synchronisation code around it.

HTH,
Phill W.