Threaded Function Overloading CPU

[f_carrie]

DWORD WINAPI ConnectionListener::ReceiveData ConnectionListener * pseudoThis){
long bytesReceived = 0;

while(1){

bytesReceived = 0;

while(bytesReceived <= 0){
bytesReceived = recv(pseudoThis->clientSocket, pseudoThis->packetBuffer, sizeof(pseudoThis->packetBuffer), 0);
}

pseudoThis->packetBufferLen = bytesReceived;
pseudoThis->packetBuffer[pseudoThis->packetBufferLen] = '\0';
cout << pseudoThis->packetBuffer << endl;
}

return 0;
}

My server will execute a new instance of this threaded function every time a new connection is made. However, even if one instance of this function is running, my CPU usage jumps to 100%. Does anyone see what the problem might be from the code above? Any information/suggestions would great!

Regards,

Fabio

[kasracer]

Loops will make a CPU go up to 100%. while(1) is never ending so it won't not get off of 100%.

Not sure of anything you can do though...

[f_carrie]

while(1) is never ending so it won't not get off of 100%

Granted, but the loop is in a threaded function so the CPU will be used at 100% during the time slice allocated to the function. I would assume that once the function is preempted the usage would drop dramatically.

Not sure of anything you can do though...

If could block at recv() (execute recv() only when I know there is data to be received) I could elimante my inner loop and my outer loop would not be in continuous execution.

Any thoughts on how this may be done?

[TDM]

Hi,

Funny you should make this post. I had a similar problem. Mine was with a thread for the serial port. I was alerted to the problem when the thermal warning on my SMBus monitor indicated that the processor was getting too hot. Looking at the CPU usage when I was running the program showed that it was running at near 50% whenever the thread was active.

I fixed the problem by putting a WaitForSingleObject along with WaitCommEvent in the thread that would wait until a data was received into the serial buffer. The processor usage is now down around 1-2% and the there is no noticable loss of performance with reading the data from the port.

One thing to note is that if there is always data to read from the network connection you'll have to use some other method.

TDM

[j0nas]

Your inner loop looks very stange... You're currently reading up to sizeof(pseudoThis->packetBuffer) bytes per iteration, until the other side shuts down or a socket error occurs.

Then (after the look), you're trying to save the legnth and print out the content of the buffer. But, bytesReceived will always be <= 0.

The CPU will probably go up to 100 % due to the outer loop (while(1))... There is no exit, so when bytesReceived is <= 0, you have a endless loop that really doesn't do anything useful (doesn't wait for IO input or anything).

[f_carrie]

I lowered the thread priority to "lowest". My usage is now stable at 0%-2% range.

if there is always data to read from the network connection you'll have to use some other method

Your right, and lucky for me I don't. I will readily be receiving data so even if higher priority threads interfere, the function can still function properly.

[TDM]

Hi

Originally quoted by f_carrie
I lowered the thread priority to "lowest". My usage is now stable at 0%-2% range.

Adjusting the thread priority was the first thing I tried. On my program the user can adjust it on one of the setup property pages for the serial port settings. It made no difference (idle priority through time critical) on a 3GHz hyper thread processor but made a huge difference on slower non-hyper thread procesors. Therefore, I chose to make the modification that would be suitable for all systems.

TDM

[Andreas Masur]

[Merged threads]

[TheCPUWizard]

I lowered the thread priority to "lowest". My usage is now stable at 0%-2% range.

Be careful, this can be a real LIE.

Many of the times when the CPU utilization is being displayed, it is done (deep internally) by subracting the amount of time that the idle process is getting from 100%.

If you lower a process priority below the idle process (or raise the idle process priority) you will get a low number reported when in fact the CPU is cranking.

The above technique is used by some viral programs as a stealth technique, and by at least one commercial program.