Programs Taking 100% CPU

[Mephisto]

How do you interpret programs which take 100% CPU but don't really seemingly hurt performance at all?  It's as of they weren't running...

[MyndFyre]

How do you interpret programs which take 100% CPU but don't really seemingly hurt performance at all?  It's as of they weren't running...

I've noticed that most of Blizzard's games do this.  Not really sure how to interpret it.  Most likely, there are a lot of calculations going on, but they're not in an infinite loop that would subvert the preemptive multitasking capabilities of Windows.

[Mephisto]

Well, I have a thread that runs in an infinite loop that most of the time reiterates constantly (a source of 100% CPU usage) but then everytime the loop iterates a call to Sleep(0); (thanks iago) is made which gets rid of the negatives of 100% CPU usage (no laggy/unwanted behavior) but it still records 100% CPU usage.

[iago]

It's probably not a good thing.  For example, on a laptop it'll eat up the battery.

You really need to put the thread into a waiting state if it's not donig anything.

[Mephisto]

It's probably not a good thing.  For example, on a laptop it'll eat up the battery.

You really need to put the thread into a waiting state if it's not donig anything.

The problem is there's nothing accessible to the thread to wait on; but I'll think of something. 

[Kp]

What's it doing that it needs to keep polling?  There's very few operations where you need to poll for new data.

[Skywing]

The program could be doing a SwitchToThread()-like call in a tight loop - this would keep the system responsive, but it's still not a very good idea for the reason iago mentioned.

Blizzard's older games have some very stupid loops without any wait or timeslice relinquishing calls in the UI code.

[Mephisto]

What's it doing that it needs to keep polling?  There's very few operations where you need to poll for new data.

The loop constantly takes data from the queue and sends it.  This psuedo code shows how it works:

VOID QueueDispatcherThread(VOID)
{
    while (bot is not marked for shutdown) {
        if (queue messages are pending) {
            SendQueuedMessage and Delay(...);
        }
        Sleep(0);
    }
}

Basically with the timesplice (Sleep(0)) it prevents it from lagging up the computer and making it noticable it's using 100% CPU usage (as oppose to if it weren't there); but I'm confused as to why it records 100% CPU usage when it doesn't even seem to be.

[Eibro]

Do this:

When the dispatcher thread notices there are no more pending sends, it suspends itself.
When you queue a send, check if the size of the send queue is 0, if it is, queue your request and wake the dispatcher thread. Else, simply just queue your send.

[iago]

I'd do it a little different than eibro:

When the dispatcher thread notices there are no more pending sends, it suspends itself.
When you queue a send, signal the dispatcher thread. 

If the dispatcher thread is already awake, life goes on.  The code will just be a little cleaner.

[Kp]

For implementing this, check out WaitForSingleObject, CreateEvent, SetEvent, ResetEvent.

[Adron]

For implementing this, check out WaitForSingleObject, CreateEvent, SetEvent, ResetEvent.

Can it be safely implemented using a single event and ResetEvent?

Would a Semaphore be better?

[Kp]

For implementing this, check out WaitForSingleObject, CreateEvent, SetEvent, ResetEvent.

Can it be safely implemented using a single event and ResetEvent?

Would a Semaphore be better?

He already has some way of keeping it from crashing despite having the queue-sending thread running full bore, so I assume he has a synchronization method in mind already.  A semaphore is another good choice, though.