# Windows – At what point will two CPU processes interfere with each other

cpucpu usageprocesswindows 7

I'm running multiple processes on my CPU simultaneously, and now I am trying to find out how much CPU power each of them can use until they start disturbing each other:

For simplicity's sake let's assume a machine with a single CPU, and assume CPU is the only resource that is relevant.

We now have two different processes running on our single CPU on a Windows 7 64-bit machine at equal CPU priority. We'll call them P1 and P2. Both P1 and P2 use 20% of the CPU each.

1. Will they both run the same way as they would if the respective other wasn't running aswell?
Logically they would since there is more than enough CPU power for both of them to run. However due to sharing of the CPU the actual situation may be different.

2. If the answer to 1. is yes: At what point will they begin interfering with each other?
Will they only begin interfering with each other once both of them try to use more than 50% of the total CPU power, or will they interfere much earlier for whatever reason?

3. Would the answers to the previous questions be different if it was more than 2 processes, or different kinds of processes (with multiple threads each for example), and how would they be different?

#### Best Answer

Ignoring overhead from the other processes (you tagged Windows 7). The kernel will queue each thread in the order that they are ready. There's a lot more in there but that's the general gist.

Each program will do many things, like make reads or writes to the disk or memory, each of these is it's own task. If each process will ever only use 20% of the CPU; P1 will get to run one task, then P2 will run one. If P2 becomes ready first in the second round P2 will run one followed by P1. This will continue until each completes and exits.

Now process utilization of 100% means that every measured time, (in this example 1 second,) so every second the processor is ALWAYS busy, and it always computing. In your example of 40% usage every second the processor is working, making calculations, for 400 milliseconds. So after 10 seconds the processor has been in standby for 6 seconds total. (Ignoring other programs, and over head)

1. Effectively yes. If you hand only one running at a time, the overhead of switching back and forth wouldn't apply, but if the processor is only at 40% it's not really an issue.

2. If each program needed 100% of the processor then you'd notice some lag time for the switching back and forth. Remember, a single core can really only do one thing at a time, it seems like it does more because it's really fast at switching back and forth. Each at 50% plus about .01% of overhead means 100.01% so you'd be "waiting" for 10 milliseconds.

3. Yes, in the intro each program had a number of tasks, with multiple threads each task the program had to do (read, and then write) would get into the queue sooner, so the "waiting" time would be less and you'd be able to pack the 40% CPU usage into the first 400 milliseconds, instead of having to include wait time forcing the work to be spread out into something like 600 milliseconds. It's effectively the same with more programs, there's more overhead for each, but it's still negligible. (Unless you get into real time systems.)

Again this is super general, but it's more or less how multiple programs share a single CPU. The issues arise when the logic/program/scheduler is bad at ordering the task queue, this causes more overhead, the more overhead the more waiting time, so even if your program needs only 40% each, the overhead of switching will cause 30% more time switching tasks or waiting around.