Threading and loops with subroutines

[OpticTygre]

Heheh...I've got lots of questions today.

If I have a loop that calls the same subroutine several times (that
subroutine may be processor and network intensive):

For i = 1 to 100
Call mySub(IPAddress(i))
Next

And inside mySub, I'm initializing a new network connection (SFTP if you
want to know). Does this loop automatically create new threads for each
subroutine that is called? I realize the loop will not wait for one sub to
finish before it calls the next. This particular loop will be finished
before the first subroutine is even finished. What is the difference
between calling something simple like this, or writing code to initiate new
threads for each sub I'm calling? Wouldn't each subroutine be working
separate from eachother already? What would be the benefit of threading
something like this?

-Jason

 

[Imran Koradia]

Well - are you saying that that is indeed what's happening? I mean - the
loop is finishing before even the first procedure returns? From the looks of
it, I really doubt that. If you call a procedure within a loop, the loop
will not continue until the first call to the procedure returns. .NET does
not spawn of new threads in such cases. In fact, there are very rare cases
in which the framework does some stuff within the code on a different thread
(eg. Timers.Timer runs on a seperate thread). So in the case you've
mentioned, the loop will be held up till the procedure call returns and then
it will continue with the next call and so on. If you want each call to
execute on a seperate thread, you would have to do that explicitly.
Considering its a 100 iteration loop, spawning off a new thread for each
call wouldn't be such a good idea since that would be quite resource
intensive. You should instead use the ThreadPool class
(System.Threading.ThreadPool) for this. The thread pool has a limit of 25
threads. So, if you run out of all 25 of them, the execution will wait till
one thread becomes free for use. Use the QueueUserWorkItem method to queue
each procedure call and the runtime will take care of executing the call on
a thread from thread pool as soon as one is available.
Here's more info on QueueUserWorkItem:
http://msdn.microsoft.com/library/d...dingthreadpoolclassqueueuserworkitemtopic.asp


hope that helps..
Imran.

 

[OpticTygre]

It's interesting you say that, Imran. If I put a messagebox.show after that
loop, and one at the end of the subroutine the loop calls, the messagebox
right after execution of the loop is the one that finishes first. That
being the case, it is apparent to me that "Calling a subroutine" will not
halt process on the main form to wait for the subroutine to finish. BTW,
the subroutine that I'm actually calling is in it's own class, and the
subroutine is being called from a module.

-Jason

 

[Imran Koradia]

It's interesting you say that, Imran. If I put a messagebox.show after
that loop, and one at the end of the subroutine the loop calls, the
messagebox right after execution of the loop is the one that finishes
first.

I don't see how that's possible. There's just one thread executing here and
that's the one going through your loop. Unless you're doing some sort of
asnyc operation or spawning a new thread or the likes in a way that'll cause
the method call to return, I don't see this happening. Maybe if you post the
code of your method it would be more clear.

That being the case, it is apparent to me that "Calling a subroutine" will
not halt process on the main form to wait for the subroutine to finish.

That is incorrect. In a standard windows application (without new threads
and all), you will only have the main UI thread and whenever you call a
subroutine, everything will halt till the procedure completes execution (or
you exit out of it explicitly or there's an exception) which is why you see
so many people complaining about their form freezing up when executing a
long running process ! (search this group for several such messages..)

BTW, the subroutine that I'm actually calling is in it's own class, and
the subroutine is being called from a module.

I'm pretty sure there's some multi-threading or asnyc operation going on
which is why you are seeing such behaviour. If you don't mind posting the
code, it would probably clear up things.


hope that helps..
Imran.

 

[OpticTygre]

I would post the code, except the fact it is for gov't work. Also, you may
be right about the async operation. I'm actually calling a subroutine
inside of a class which itself spawns new threads (I think). It uses an
external dll, and most likely that's what's happening. Thanks for the info
on threading. I've actually never used it, and just like everyone else, for
quick results I've just used Application.DoEvents() to keep the program from
freezing. heheh. I know. It's the lazy way out, but with deadlines, what
can you do? Especially when I don't know anything about threading.
Definately something I will look into, though. Thanks again.

-Jason

 

[Imran Koradia]

I would post the code, except the fact it is for gov't work.

Well - I would have loved to see what top secret code gov't folks write..
;-) just kidding..

Also, you may be right about the async operation. I'm actually calling a
subroutine inside of a class which itself spawns new threads (I think). It
uses an external dll, and most likely that's what's happening. Thanks for
the info on threading.

hmm..I suspected that...

I've actually never used it, and just like everyone else, for quick
results I've just used Application.DoEvents() to keep the program from
freezing. heheh. I know. It's the lazy way out, but with deadlines,
what can you do? Especially when I don't know anything about threading.
Definately something I will look into, though.

Same here - I'd use DoEvents picking up on the old VB6 habits and if a piece
of code ain't broke, don't change it Apparently, threading is something
people choose as a last resort since not getting it right (which in itself
is a pain) can lead to subtle bugs that are more often than not a pain in
the neck to debug. It needs a little more practice than other stuff, that's
all.

Thanks again.

you're welcome !


Imran.