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...

[quote author=Mephisto link=topic=9760.msg90889#msg90889 date=1102050697]
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...
[/quote]

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.

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.

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.

[quote author=iago link=topic=9760.msg90910#msg90910 date=1102080719]
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.
[/quote]

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

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

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.

[quote author=Kp link=topic=9760.msg90925#msg90925 date=1102091344]
What's it doing that it needs to keep polling?  There's very few operations where you need to poll for new data.
[/quote]

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.

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.

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.

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

[quote author=Kp link=topic=9760.msg90964#msg90964 date=1102117524]
For implementing this, check out WaitForSingleObject, CreateEvent, SetEvent, ResetEvent.
[/quote]

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

Would a Semaphore be better?

[quote author=Adron link=topic=9760.msg90968#msg90968 date=1102119827][quote author=Kp link=topic=9760.msg90964#msg90964 date=1102117524]For implementing this, check out WaitForSingleObject, CreateEvent, SetEvent, ResetEvent.[/quote]Can it be safely implemented using a single event and ResetEvent?

Would a Semaphore be better?[/quote]

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.