Connecting Tech Pros Worldwide Forums | Help | Site Map

Thread.Sleep slowing down the whole application

davidst95@gmail.com
Guest
 
Posts: n/a
#1: Nov 12 '06
Hello,

I have a program that runs a long process. I tried to add a thread
to check if the use hit a cancel button to abort the process.

Dim t As Threading.Thread
t = New Threading.Thread(AddressOf StartProcess)
t.IsBackground = True
t.Priority = ThreadPriority.Highest
t.Start()

Do

Thread.CurrentThread.Sleep(500)
Application.DoEvents()
if bCancel=true then
t.Abort()
exit do
end if

Loop


When I add 'StartProcess' into a thread, it's about twice as slow if it
just ran it without a thread. Could anyone tell me what I'm not doing
right? Thanks. I played around with this all day and I'm lost.
Thanks.

David


Spam Catcher
Guest
 
Posts: n/a
#2: Nov 12 '06

re: Thread.Sleep slowing down the whole application


davidst95@gmail.com wrote in news:1163365534.236771.249840
@m7g2000cwm.googlegroups.com:
Quote:
Hello,
>
I have a program that runs a long process. I tried to add a thread
to check if the use hit a cancel button to abort the process.
>
Dim t As Threading.Thread
t = New Threading.Thread(AddressOf StartProcess)
t.IsBackground = True
t.Priority = ThreadPriority.Highest
t.Start()
>
When I add 'StartProcess' into a thread, it's about twice as slow if it
just ran it without a thread. Could anyone tell me what I'm not doing
right? Thanks. I played around with this all day and I'm lost.
Thanks.

I noticed that you set the thread priority to highest - I think when it's
set to highest, it will not yield CPU time to other processes.

You should leave the thread priority to normal and try again.

Also, take a look at callback functions - depending on the situation,
they're abit better than firing a thread to run a long running function.

Dennis K.
Guest
 
Posts: n/a
#3: Nov 12 '06

re: Thread.Sleep slowing down the whole application


On Sun, 12 Nov 2006 21:55:01 GMT, Spam Catcher <spamhoneypot@rogers.com>
wrote:
Quote:
>Also, take a look at callback functions - depending on the situation,
>they're abit better than firing a thread to run a long running function.
Could you give a small example?

--

Dennis K.
Spam Catcher
Guest
 
Posts: n/a
#4: Nov 13 '06

re: Thread.Sleep slowing down the whole application


Dennis K. <nobody@iglou.invalidwrote in
news:1vafl2lk575kg304dk5urumfj0395ju5i0@4ax.com:
Quote:
On Sun, 12 Nov 2006 21:55:01 GMT, Spam Catcher <spamhoneypot@rogers.com>
wrote:
>
Quote:
>>Also, take a look at callback functions - depending on the situation,
>>they're abit better than firing a thread to run a long running function.
>
Could you give a small example?
>
Here you go:

http://msdn.microsoft.com/library/de...l=/library/en-
us/cpguide/html/cpovrasynchronousprogrammingoverview.asp

You'll probably want the example: "Executing a Callback Method When an
Asynchronous Call Completes" or "Polling for Asynchronous Call Completion".
davidst95@gmail.com
Guest
 
Posts: n/a
#5: Nov 13 '06

re: Thread.Sleep slowing down the whole application


Thank you very much for the information. I been playing around with
it all day. I have to wait until tomorrow to try this out but I think
this might work.

David


Spam Catcher wrote:
Quote:
Dennis K. <nobody@iglou.invalidwrote in
news:1vafl2lk575kg304dk5urumfj0395ju5i0@4ax.com:
>
Quote:
On Sun, 12 Nov 2006 21:55:01 GMT, Spam Catcher <spamhoneypot@rogers.com>
wrote:
Quote:
>Also, take a look at callback functions - depending on the situation,
>they're abit better than firing a thread to run a long running function.
Could you give a small example?
>
Here you go:
>
http://msdn.microsoft.com/library/de...l=/library/en-
us/cpguide/html/cpovrasynchronousprogrammingoverview.asp
>
You'll probably want the example: "Executing a Callback Method When an
Asynchronous Call Completes" or "Polling for Asynchronous Call Completion".
Robinson
Guest
 
Posts: n/a
#6: Nov 13 '06

re: Thread.Sleep slowing down the whole application



Quote:
Dim t As Threading.Thread
t = New Threading.Thread(AddressOf StartProcess)
t.IsBackground = True
t.Priority = ThreadPriority.Highest
t.Start()
Good, you've created a new thread :)
Quote:
>
Do
>
Thread.CurrentThread.Sleep(500)
Application.DoEvents()
if bCancel=true then
t.Abort()
exit do
end if
>
Loop
>
Ahh, you are sleeping the CurrentThread, which is your main thread, not the
thread you created. So, instead of sleeping there, you should sleep in
StartProcess. Secondly, it's rather bad to call "t.Abort". You will get no
end of problems especially if your thread is handling COM objects. The
accepted pattern for dealing with threads is to flag a "bCancel" inside the
thread that it checks periodically so it can terminate cleanly.

Quote:
>
When I add 'StartProcess' into a thread, it's about twice as slow if it
just ran it without a thread. Could anyone tell me what I'm not doing
right? Thanks. I played around with this all day and I'm lost.
Thanks.
>
David
>

davidst95@gmail.com
Guest
 
Posts: n/a
#7: Nov 13 '06

re: Thread.Sleep slowing down the whole application


Thanks for the reply. Wouldn't "t.Sleep(1000)' just slow down the
whole thread? I tried it out and have similar results. What I want
to try to do is run a thread and have another thread refresh the form
and check the cancel button without slowing down the 'StartProcess'
thread.

When I remove the thread itself and just run 'StartProcess', the time
decreases in half.

Thanks again.

David


Robinson wrote:
Quote:
Quote:
Dim t As Threading.Thread
t = New Threading.Thread(AddressOf StartProcess)
t.IsBackground = True
t.Priority = ThreadPriority.Highest
t.Start()
>
Good, you've created a new thread :)
>
Quote:

Do

Thread.CurrentThread.Sleep(500)
Application.DoEvents()
if bCancel=true then
t.Abort()
exit do
end if

Loop
>
Ahh, you are sleeping the CurrentThread, which is your main thread, not the
thread you created. So, instead of sleeping there, you should sleep in
StartProcess. Secondly, it's rather bad to call "t.Abort". You will get no
end of problems especially if your thread is handling COM objects. The
accepted pattern for dealing with threads is to flag a "bCancel" inside the
thread that it checks periodically so it can terminate cleanly.
>
>
Quote:

When I add 'StartProcess' into a thread, it's about twice as slow if it
just ran it without a thread. Could anyone tell me what I'm not doing
right? Thanks. I played around with this all day and I'm lost.
Thanks.

David
Robinson
Guest
 
Posts: n/a
#8: Nov 13 '06

re: Thread.Sleep slowing down the whole application



<davidst95@gmail.comwrote in message
news:1163428883.308461.208140@i42g2000cwa.googlegr oups.com...
Quote:
Thanks for the reply. Wouldn't "t.Sleep(1000)' just slow down the
whole thread? I tried it out and have similar results. What I want
to try to do is run a thread and have another thread refresh the form
and check the cancel button without slowing down the 'StartProcess'
thread.
>
When I remove the thread itself and just run 'StartProcess', the time
decreases in half.
>
Thanks again.
>
David
>
>
Robinson wrote:
Quote:
Quote:
Dim t As Threading.Thread
t = New Threading.Thread(AddressOf StartProcess)
t.IsBackground = True
t.Priority = ThreadPriority.Highest
t.Start()
>>
>Good, you've created a new thread :)
>>
Quote:
>
Do
>
Thread.CurrentThread.Sleep(500)
Application.DoEvents()
if bCancel=true then
t.Abort()
exit do
end if
>
Loop
>
>>
>Ahh, you are sleeping the CurrentThread, which is your main thread, not
>the
>thread you created. So, instead of sleeping there, you should sleep in
>StartProcess. Secondly, it's rather bad to call "t.Abort". You will get
>no
>end of problems especially if your thread is handling COM objects. The
>accepted pattern for dealing with threads is to flag a "bCancel" inside
>the
>thread that it checks periodically so it can terminate cleanly.
>>
>>
Quote:
>
When I add 'StartProcess' into a thread, it's about twice as slow if it
just ran it without a thread. Could anyone tell me what I'm not doing
right? Thanks. I played around with this all day and I'm lost.
Thanks.
>
David
>
>
Oh okay, I misunderstood. I thought you were wanting to sleep the worker
thread so it didn't take too much time away from the main GUI thread (which
is the more normal scenario). I suggest you re-archietect what you are
doing slightly. Let your worker thread run free inside a loop checking for
"cancelled = true", at which point it exits. You then can "fire and forget"
the worker thread.

When your main thread is finished, it can "invoke" a delegate on your form
to say it's finished, or a delegate to say it was cancelled or a delegate to
say it was failed (or you can put all 3 into the same method).

Something like this:

User Action
Create Thread
Start Thread (
[Thread loops doing it's business]
[If bCancelled Then Exit Thread]
Exit:
Invoke Completed Method on Main Form )

Completed:
Update UI





Closed Thread