High CPU Usage with Threads / Sockets

[ryantroop]

Hi all,

So before I went and posted ~800 lines of code, I have 2 questions:

1: What is the preferred way for us to post "complex" C++ (of course, this is just a .h, .cpp, and main cpp but it's still a lot of lines) that wont just be obnoxious to read/debug? (I guess.. what is the proper etiquette here?)

2: Maybe I don't have to post it, and I can get theory help - I have a socket server that spawns threads with mutexes to control everything as needed (I think I am doing it right). When I run on my dev machine (4 cores), I get about 22% usage spikes every 5 seconds on 2 of the cores. When I put it on my "server" it's a single core, and it spikes to 100%.

I have put std::couts in all the while loops and none of them run more than the initial entry (recv/accept are blocking, all the other mutexes hold just fine). Is there a better approach to debugging this, or are accept/recv just that cpu intensive?

I am not yet doing event driven threads (and I am not using select, but if I have to I will refactor, but I would like to understand how to do it "right" without it as part of the learning exercise).

For reference: Windows server 2012 R2, Single Core 2Ghz, 1Gb RAM. IIS is running, the server is fairly locked down and all security updates/patches are installed. I do monitor any additional processes running, and nothing is odd or unexpected on the vm.

Threads are created using CreateThread(...); Mutexes are locked with WaitForSingleObject(...);

Sorry for the length, and thank you!

Ryan

[rproffitt]

At the office we don't have a single single core machine left. The last lowly machine we had and someone stole it was a 2006 Dell E1505 Core Duo with 1GB RAM and 120GB SSD. You must have something even older.

On such a machine I see nothing wrong with 100% CPU and 100% everything. It's what it is. Since it's just a single core, all those threads would be dragging it down even more.

I can't guess what the goal here with a server that looks to cost less than Windows Server 2012. Tell your story. Sounds interesting.

[ryantroop]

It's just a test VM so I can practice. I spend most of my day writing JS/SQL/CSS and we use a propretary C++ backend, and I want to contribute more to what my company does - in order to do so, I am trying to improve my skills with C++ and programming in general by writing applications and filling in knowledge gaps.

Why the single core VM? Was the best price I could find.

IIS runs on the machine and it idles at 3%. Socket programming cant possible be that heavy that I can't replicate what IIS does. I get that I don't have the development power of Microsoft nor the inner workings of the OS at my disposal, but I would think that 100% is a bit obnoxious :-/

[rproffitt]

About replicate what IIS does. Think about the years IIS and other systems with hundreds of programmers have been working on this.

Now, for your first expedition I don't think it's bad to need more cores and RAM. You'll get better with time.

That is, you don't come in 1st or even place well in your first races.

Again, I see nothing wrong with high CPU use with so little resources.

[rproffitt]

About 100% CPU use in a loop. That's not unusual at all. You do need to move to an event driven system to get rid of an infinite loop.

Example at https://stackoverflow.com/questions/7402146/cpu-friendly-infinite-loop

[ryantroop]

That whole thread is about using Sleep() or Event Objects to work as a shared handle for signaling. :-P

Unless I missed something else in there that you would like to point out.

If that's the answer then so be it - event driven programming is fine. I do it in JS all the time... was just thinking there was something more effective in C++ (or, rather, I assumed it would be different....)

[rproffitt]

The reply below is about an exit and "To avoid the infinity loop simply use a WaitHandle. To let the process be exited from the outer world use a EventWaitHandle with a unique string. Below is an example."

If you simply had a loop, then CPU should go to 100%. Sticking Sleep() in that loop would only limit what amount of work the loop could dispatch. This is why we choose to go simple at first (get it done!) and later refine to event driven designs.

[ryantroop]

So, turns out the sockets were a red herring. I had a "reader" thread that basically shot through a linked list of "message" objects, and if that list was empty the thread was spinning like mad.

So.. future folks looking for help with threads - even when you check all your while loops and put testing in, go ahead and do it twice :-/ You missed one.