Processor usage in VB program

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I'm writing a VB.Net 1.1 app that has to listen for messages coming to it via
TCP/IP.

When one arrives it it queued and then processed on a seperate thread while
the main thread goes back to listening for more.

When I look at the Task Manager, it shows that the program is taking up 100%
of the processor unless another application needs to run. Is this normal? Do
I need to worry? If so is there any way of modifying the main listening task
so that it is not using so much of the resources?

I'm still quite new to VB.Net so please try to keep things simple!

Thanks
 
Hi,
in your loops, try to insert a System.Threading.Thread.Sleep(sleepTimeInMs)
somewhere (usually just before the end of the loop)... it will probably
help...

I hope it helps

ThunderMusic
 
John S said:
I'm writing a VB.Net 1.1 app that has to listen for messages coming to it via
TCP/IP.

When one arrives it it queued and then processed on a seperate thread while
the main thread goes back to listening for more.

When I look at the Task Manager, it shows that the program is taking up 100%
of the processor unless another application needs to run. Is this normal? Do
I need to worry? If so is there any way of modifying the main listening task
so that it is not using so much of the resources?

I'm still quite new to VB.Net so please try to keep things simple!

No, that's not normal.

Could you post a short but complete program which demonstrates the
problem?

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.
 
When one arrives it it queued and then processed on a seperate thread while
the main thread goes back to listening for more.

When I look at the Task Manager, it shows that the program is taking up 100%
of the processor unless another application needs to run. Is this normal?

No, not normal. One thread or the other is consuming cpu cycles, and you
need to fix that. I suggest you not start the worker thread - let the main
thread keep enqueuing and let the queue grow. If you are still pegged at
100%, then the culprit is the main thread, if not, the culprit is the worker
thread.

In any case, the question to ask yourself is this: when nothing is going
on, what are the threads doing? All threads should be blocked by something
so that the system idle process is pegged at nearly 100%. The main thread
should be blocked listening for incoming data. The worker thread should
either be not running or blocked on something under the control of the main
thread.
 
Jon,
I've been accessing the newsgroup through IE and don't seem to get an option
for attaching code.

I think the problem is probably something to do with me using the main
thread to listen for the incoming messages.

Using VB.net, I have a method which runs a while loop roughly like the
following:

While blnRunProgram
If Not TcpListener1.Pending Then
Application.DoEvents
Else
Place the incoming message on the queue etc
End If
End While

Does that help?
 
John S said:
I've been accessing the newsgroup through IE and don't seem to get an option
for attaching code.

Just post it inline - cut and paste into the article.
I think the problem is probably something to do with me using the main
thread to listen for the incoming messages.

If it's a UI thread, that's certainly not a great idea.
Using VB.net, I have a method which runs a while loop roughly like the
following:

While blnRunProgram
If Not TcpListener1.Pending Then
Application.DoEvents
Else
Place the incoming message on the queue etc
End If
End While

Does that help?

That would certainly explain things - you've basically got a tight loop
there.

Listen in a different thread (with blocking calls) or accept
connections asynchronously.
 
As I said before, I'm fairly new to this and have to admit I don't fully
understand what you said.

I think I could work out how to run the the Listener on another thread but
don't know what blocking calls are. Is that where you tell the thread to
sleep for a short while?

I don't see how accepting the calls asynchronously would help a great deal
as it's not the calls that appear to be the problem. It seems more like the
fact that because I have no idea when the next call may be sent, The listener
has to sit waiting all the time.
 
John S said:
As I said before, I'm fairly new to this and have to admit I don't fully
understand what you said.

I think I could work out how to run the the Listener on another thread but
don't know what blocking calls are. Is that where you tell the thread to
sleep for a short while?

No - it's where you make a call (Read, Accept etc) that doesn't return
until it's read some data, accepted a connection etc.
I don't see how accepting the calls asynchronously would help a great deal
as it's not the calls that appear to be the problem. It seems more like the
fact that because I have no idea when the next call may be sent, The listener
has to sit waiting all the time.

Yes, the listener has to sit waiting for events - but if you use a
block call, it can do so without looping round, and if you do it in a
different thread, it won't make the UI freeze.
 
Hi,

Thanks for all you time.

I think that I understand what you're saying now but don't have a clue how
or where to start actually programming it. For some reason, I seem to have a
mental block when it comes to threading.

Can you suggest any books, code examples etc that might help? I've tried
looking through MSDN and can't seem to put things together from there and
there seems to be very little about threading etc in most of the general
VB.Net books that we have in the office.

Any suggestions would be gratelly welcomed.
 
John S said:
Thanks for all you time.

I think that I understand what you're saying now but don't have a clue how
or where to start actually programming it. For some reason, I seem to have a
mental block when it comes to threading.

Can you suggest any books, code examples etc that might help? I've tried
looking through MSDN and can't seem to put things together from there and
there seems to be very little about threading etc in most of the general
VB.Net books that we have in the office.

Any suggestions would be gratelly welcomed.

Well, my own article on threading (over several pages) is here:

http://www.pobox.com/~skeet/csharp/threads

Don't feel bad about finding threading hard - it's fiendish. Those who
feel they can do it easily are almost certainly wrong :)
 
Wow, that's more like an encyclopedia!

Well with that and something I finally found in MSDN written in VB.NET I
think I'm getting there.

I now have a test version of my program which is not hogging the processor
with the GUI, Listener and Data processor all running on seperate threads.

Just 1 more question now.

What do you do about exceptions in the worker processes? They don't seem to
escalate up to the GUI so do you have to raise your own event in the catch
statement as a callback?
 
John S said:
Wow, that's more like an encyclopedia!

Well, there's a lot to threading...
Well with that and something I finally found in MSDN written in VB.NET I
think I'm getting there.

I now have a test version of my program which is not hogging the processor
with the GUI, Listener and Data processor all running on seperate threads.

Just 1 more question now.

What do you do about exceptions in the worker processes? They don't seem to
escalate up to the GUI so do you have to raise your own event in the catch
statement as a callback?

I assume you mean worker threads, not worker processes. You can
subscribe to the AppDomain.UnhandledException event - but as far as I'm
aware, that event will be fired on the thread which throws the
exception, so you'll still need to marshall to the UI thread to notify
the user.
 
Back
Top