469,625 Members | 1,526 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,625 developers. It's quick & easy.

Threads very slow

PH
Hi guys;

I got a single processor computer, running an application that launches
2 threads.

Each of these threads listens for incoming connections in a specific
port, so there is a Loop . Until inside each of them.

When a packet is received the thread calls a method that process the
packet, and so on, this happens for every packet in any of those 2
ports.

THIS SI NOT THE ACTUAL CODE, BUT IS SOMETHING ALIKE

--------------------------

Dim Thread1 as new Thread (addressOff ProcessPacket)

Thread1.Start

Dim Thread2 as new Thread (addressOff ProcessPacket)

Thread2.Start

Private Sub ProcessPacket

Do

BeginAccept( WhateverProc)

Until bStop

End Sub

Private Sub WhateverProc

Process the packet

End Sub

--------------------------

Now, my problem is that in a period of time, lets say 30 seconds, I only
receive 4 packets (this is only when I test, in production will be a LOT
more, believe me ;-) )

What happens is that the processor's resources are almost gone, and the
computer reacts responsive less.

If this is happening with 4 packets, I don't what to even imagine what
will happen with 100.

Is there any way to easy the life of the processor even with more
traffic coming in?

Thanks


Mar 7 '06 #1
5 3969
BeginAccept shouldn't be in a loop.

Call it once. Then when the connection occurs, your method will be
called to handle the connection event.

To receive a packet, use Recieve or BeginReceive.

Mar 7 '06 #2
Not to mention you have both those threads running full throttle without
yielding processor time when there is no work to do ... of course it's
going to consume your cycles.... but then that would only apply if you
are using Recieve vs. BeginReceive ..

John
Andy wrote:
BeginAccept shouldn't be in a loop.

Call it once. Then when the connection occurs, your method will be
called to handle the connection event.

To receive a packet, use Recieve or BeginReceive.

Mar 7 '06 #3
PH

Hi John, could you please be a little more specific?
Like with any example or a way to improve the code?

Are you talking about application.doevents() ?

Thanks
-----Original Message-----
From: John Murray [mailto:jm*****@pluck.com]
Posted At: Tuesday, March 07, 2006 12:38 PM
Posted To: microsoft.public.dotnet.languages.csharp
Conversation: Threads very slow
Subject: Re: Threads very slow

Not to mention you have both those threads running full throttle without

yielding processor time when there is no work to do ... of course it's
going to consume your cycles.... but then that would only apply if you
are using Recieve vs. BeginReceive ..

John
Andy wrote:
BeginAccept shouldn't be in a loop.

Call it once. Then when the connection occurs, your method will be
called to handle the connection event.

To receive a packet, use Recieve or BeginReceive.


Mar 7 '06 #4
There are a couple of approaches ...

Using Socket.Accept() in blocking mode will block while awaiting a
connection, in a thread efficient manner .. so additional code to yield
the thread is not necessary.

Using Socket.BeginAccept(), you dont need to launch the seperate thread
because the socket is going to use a different thread once data is
recieved on that socket. This would also be an efficient mechanism
because your thread isnt spending a lot of time doing a useless loop.
It should be noted that this will not cause your original thread to block.

The note about yielding the thread was more specific as a coding style.
Effectively the loop was doing something like:

while(true)
{
/* do nothing */
}

which is going to peg the processor. As for doEvents -- generally I
would say you never should have to use that nasty hack in .NET.
Remember, doevents is not yielding the thread, it's waiting for the
message pump to process an additional message -- so if you arent in a
windows forms app, or are running in a multithreaded environment it's
not giving you any benefit.

If you want to allow the thread to yield time to other threads ... one
of these might be a better option

Thread.SpinWait
or
Thread.Sleep

depending on your requirements....
Of course, I have a bad habit of answering the wrong question -- please
let me know if I have done that this time.
PH wrote:
Hi John, could you please be a little more specific?
Like with any example or a way to improve the code?

Are you talking about application.doevents() ?

Thanks
-----Original Message-----
From: John Murray [mailto:jm*****@pluck.com]
Posted At: Tuesday, March 07, 2006 12:38 PM
Posted To: microsoft.public.dotnet.languages.csharp
Conversation: Threads very slow
Subject: Re: Threads very slow

Not to mention you have both those threads running full throttle without

yielding processor time when there is no work to do ... of course it's
going to consume your cycles.... but then that would only apply if you
are using Recieve vs. BeginReceive ..

John
Andy wrote:
BeginAccept shouldn't be in a loop.

Call it once. Then when the connection occurs, your method will be
called to handle the connection event.

To receive a packet, use Recieve or BeginReceive.

Mar 7 '06 #5
PH

You did just great ;-)
I appreciate a lot!
I'm going to try it tonight
-----Original Message-----
From: John Murray [mailto:jm*****@pluck.com]
Posted At: Tuesday, March 07, 2006 3:03 PM
Posted To: microsoft.public.dotnet.languages.csharp
Conversation: Threads very slow
Subject: Re: Threads very slow

There are a couple of approaches ...

Using Socket.Accept() in blocking mode will block while awaiting a
connection, in a thread efficient manner .. so additional code to yield
the thread is not necessary.

Using Socket.BeginAccept(), you dont need to launch the seperate thread
because the socket is going to use a different thread once data is
recieved on that socket. This would also be an efficient mechanism
because your thread isnt spending a lot of time doing a useless loop.
It should be noted that this will not cause your original thread to
block.

The note about yielding the thread was more specific as a coding style.
Effectively the loop was doing something like:

while(true)
{
/* do nothing */
}

which is going to peg the processor. As for doEvents -- generally I
would say you never should have to use that nasty hack in .NET.
Remember, doevents is not yielding the thread, it's waiting for the
message pump to process an additional message -- so if you arent in a
windows forms app, or are running in a multithreaded environment it's
not giving you any benefit.

If you want to allow the thread to yield time to other threads ... one
of these might be a better option

Thread.SpinWait
or
Thread.Sleep

depending on your requirements....
Of course, I have a bad habit of answering the wrong question -- please
let me know if I have done that this time.
PH wrote:
Hi John, could you please be a little more specific?
Like with any example or a way to improve the code?

Are you talking about application.doevents() ?

Thanks
-----Original Message-----
From: John Murray [mailto:jm*****@pluck.com]
Posted At: Tuesday, March 07, 2006 12:38 PM
Posted To: microsoft.public.dotnet.languages.csharp
Conversation: Threads very slow
Subject: Re: Threads very slow

Not to mention you have both those threads running full throttle without
yielding processor time when there is no work to do ... of course it's going to consume your cycles.... but then that would only apply if you are using Recieve vs. BeginReceive ..

John
Andy wrote:
BeginAccept shouldn't be in a loop.

Call it once. Then when the connection occurs, your method will be
called to handle the connection event.

To receive a packet, use Recieve or BeginReceive.


Mar 7 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by Ralph Sluiters | last post: by
1 post views Thread by Doug | last post: by
6 posts views Thread by Quiet Man | last post: by
4 posts views Thread by David Travis | last post: by
5 posts views Thread by Mr | last post: by
7 posts views Thread by Michael | last post: by
18 posts views Thread by Jon Slaughter | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.