Prev: Question about ImageList
Next: error BC30560: 'LoginServiceEng' is ambiguous in the namespace...
From: Jesse Aufiero on 6 Jul 2007 08:41
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!


From: Armin Zingler on 6 Jul 2007 09:44
"Jesse Aufiero" <jaufiero(a)moaboil.com> schrieb
> 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

From: Phill W. on 6 Jul 2007 11:05
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.
From: Jesse Aufiero on 6 Jul 2007 12:22
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-k> wrote in message
news:f6llo1$1lq$1(a)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.


From: Phill W. on 9 Jul 2007 08:40
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.
 | 
Pages: 1
Prev: Question about ImageList
Next: error BC30560: 'LoginServiceEng' is ambiguous in the namespace...