I'm referring to Windows 10 operating system, but I believe the answer might be OS independent.
On windows, the real-time priority level is the highest priority level, use to process keyboard and mouse input for instance.
From what I read online:
Setting a CPU-intensive process to real-time means that the keyboard and the mouse will become unresponsive because the OS won't get enough CPU time to process these inputs.
Basically, a process set to real-time priority will execute without giving the CPU to any other processes, not even the task manager. If something goes wrong, you won't be able to stop it.
See for instance this Microsoft post: When you set a 100% CPU program to real-time priority, you get what you asked for.
Question:
So all this make me afraid to test this level of priority on my machine, which is why I'm asking this question instead of trying it out myself. Also, a theoretical answer seems more future proof than trying with a toy script.
If I run a single-threaded process with real-time priority, I understand that it will execute without stopping until it is finished. But if I have a second core, will I be able to use my PC while this process is running thanks to this second core ?
If yes, this has practical applications. I can run a computational task whose result I need asap on one core while still being able to use my PC with the other core.
Answer
If I run a single-threaded process with real-time priority, I understand that it will execute without stopping until it is finished.
That is an exaggeration. There are several things that make it not-true:
What you see in Task Manager as "real-time priority" is actually a range of priorities that the process's threads can access. It's possible for one "real-time" process's threads to have higher priorities than those of another "real-time" process. See my answer here. However, all priorities within the "real-time" class are higher than any of the priorities in all of the other classes.
Most threads don't spend all their code spinning in the CPU, so they won't use 100% of the CPU regardless of their priority. Most threads do have occasion to wait for things now and then. Usually they're waiting for an I/O to complete, or for a hard page fault to be resolved, or for some other thread to indicate that they don't have to wait any more. (The other thread could be in the same process or in a different one.)
The first stages of handling of interrupts from hardware devices (including interrupts from the real-time clock) happen regardless of any thread-based code. This stuff doesn't have a "priority" as priority is an attribute of a thread, but interrupts aren't handled by threads. They take precedence over thread-based code regardless of the latter's priority. You can see the time used by this stuff as "System interrupts" in the Details tab of Windows 10's Task Manager.
The real-time priority class is different from the other priority classes in these ways:
It's higher priority than all the other priority classes (of course).
Threads of processes in this class do not get their priorities automatically adjusted depending on their recent activity, as do threads of processes in other classes, by default. (Thread priority adjustment can be turned off and on programmatically, but by default it's on for non-realtime processes.)
But if I have a second core, will I be able to use my PC while this process is running thanks to this second core ?
Probably. In fact, this is true even if you have only one core that has hyperthreading enabled.
The proper use of the real-time priority class is NOT for a CPU-intensive process. Rather, we use high priorities for tasks that need to respond quickly to events. Intensive CPU-based work in response to those events should be done at low priorities, ideally at below "normal" so as to stay out of the way of interactive users.
No comments:
Post a Comment