Threads very slow | | |
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 | | | | re: Threads very slow
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. | | | | 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:[color=blue]
> 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.
>[/color] | | | | re: Threads very slow
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:jmurray@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:[color=blue]
> 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.
>[/color] | | | | 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:[color=blue]
> 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:jmurray@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:[color=green]
>> 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.
>>[/color]
>[/color] | | | | re: Threads very slow
You did just great ;-)
I appreciate a lot!
I'm going to try it tonight
-----Original Message-----
From: John Murray [mailto:jmurray@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:[color=blue]
> 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:jmurray@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[/color]
without[color=blue]
>
> yielding processor time when there is no work to do ... of course it's[/color]
[color=blue]
> going to consume your cycles.... but then that would only apply if you[/color]
[color=blue]
> are using Recieve vs. BeginReceive ..
>
> John
>
>
> Andy wrote:[color=green]
>> 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.
>>[/color]
>[/color] |  | Similar C# / C Sharp bytes | | | /bytes/about
We are a network of experts and professionals in IT and software development that help one another with answers to tough questions and share insights.
Get the best answers to your questions from over 226,537 network members.
|