cpu usage %

Theoretically you could write your own code with timers, and to get the percentage, you would just divide the time elapsed by the time your thread is active.

But why are you trying to do this?

Quote:

Original post by Lukewarm Theoretically you could write your own code with timers, and to get the percentage, you would just divide the time elapsed by the time your thread is active.

thats not what i need to do nor will it give what i need

Quote:

But why are you trying to do this?

i have a low priority background task that i wonna run such that it doesnt hog the cpu from other procs
for that i need to be able to find global processor usage, processor idleness, and etc.

Quote:

Original post by caesar4 i have a low priority background task that i wonna run such that it doesnt hog the cpu from other procs for that i need to be able to find global processor usage, processor idleness, and etc.

Can't you just set your thread to low priority and let the OS handle the rest? That's what priorities are their for.

So long as you use blocking wait functions wherever possible, or make frequent calls to Sleep(), there shouldn't be any problems. I believe it's possible to find out the processor usage overall via some system performance information call, but I don't know what the call is offhand.

GetProcessTimes()
GetThreadTimes()

This article might help: Developing WMI Hi-Perf Provider using C++

Quote:

Original post by Agony GetProcessTimes() GetThreadTimes()

thank you thank you thank you


now, how can use that to get the idle percent?
i know i need to use the kernel and user times deltas, but how do i find the kernel and user times for ALL processes combined?

If you have a low-priority process, it pretty much by definition won't hog the CPU.
Windows always runs the available process with the highest priority. Your app will *only* run if everything else keeps yielding the cpu.

I would go with the low priority+frequent sleep approach.

Attempting to manually throttle your program to some desired CPU usage will always be a hack at best (and hacks are bad). As soon as you run it on a dual core processor, or down the road when some setup like dual cores acting as one CPU comes out, it will break and likely do the exact opposite of what you intended.

Quote:

Original post by Spoonbender If you have a low-priority process, it pretty much by definition won't hog the CPU. Windows always runs the available process with the highest priority. Your app will *only* run if everything else keeps yielding the cpu.

the thread sometimes needs to be background, sometimes, it needs to hog ondemmand


a low priority thread is out of the question, since this is regarding a memory manager that can and does move objects around, so a low priority will slow down other parts of code that need the manager to quickly finish its current operation

already implementing the sleep approach, but i need variable sleep, depending on cpu usage

no more anything about setting the thread to low priority please