.NET Real-Time 和 TaskMgr Real-time 优先级类有什么区别？

Question

When I set a process' priority class to real-time in .NET:

Process.GetCurrentProcess().PriorityClass = ProcessPriorityClass.RealTime;

It appears only as "High" priority in Task Manager:

If I manually set it to Real time in Task Manager and then do Process.GetCurrentProcess() again, the ProcessPriorityClass is still reported as ProcessPriorityClass.RealTime .

If I run the app as admin, then the priority class does change to Real time, as reported by Task Manager. So it appears that when running as a normal user, you can set it to RealTime and it will be reported as such by .NET, but the actual priority of the process is actually just High. Why do .NET and TaskManager report different values in this case?

Answer 1

The real culprit here is Windows.

The setter of the PriorityClass property is straightforward:

 set {
        if (!Enum.IsDefined(typeof(ProcessPriorityClass), value)) { 
            throw new InvalidEnumArgumentException("value", (int)value, typeof(ProcessPriorityClass));
        }

        // BelowNormal and AboveNormal are only available on Win2k and greater.
        if (((value & (ProcessPriorityClass.BelowNormal | ProcessPriorityClass.AboveNormal)) != 0)   && 
            (OperatingSystem.Platform != PlatformID.Win32NT || OperatingSystem.Version.Major < 5)) {
            throw new PlatformNotSupportedException(SR.GetString(SR.PriorityClassNotSupported), null);
        }                

        SafeProcessHandle handle = null;

        try {
            handle = GetProcessHandle(NativeMethods.PROCESS_SET_INFORMATION);
            if (!NativeMethods.SetPriorityClass(handle, (int)value)) {
                throw new Win32Exception();
            }
            priorityClass = value;
            havePriorityClass = true;
        }
        finally {
            ReleaseProcessHandle(handle);
        }
    }

After a few sanity checks, it calls the Windows API SetPriorityClass , then it checks the return code. If an error occurs, it throws an exception. Otherwise, it stores locally the value of the new priority (so that, when you read the value of PriorityClass , it doesn't have to call Windows back to check it).

In some conditions, Windows will deny the change of priority (for instance, as you noticed, you now need administrator privileges to set the real-time priority). The trick is that Windows denies the priority change silently and does not return an error code . As documented here :

Note that the call to SetPriorityClass() may return success even though the priority was not set to REALTIME_PRIORITY_CLASS, because if you don't have the Increase Scheduling Priority permission, a request for REALTIME_PRIORITY_CLASS is interpreted as a request for the highest priority class allowed in the current account.

I'm guessing this is done to avoid breaking legacy applications that wouldn't expect their call to fail. Because of this, your .NET application is not aware that the priority change didn't work as expected, and returns the wrong value.

---

That said, even if Windows did set the priority as expected, the .NET code still wouldn't work in some cases. For instance, imagine you were setting the PriorityClass to BelowNormal . That value would be stored locally in the Process object, as explained above. Then if you change the priority again but from the task manager, just like before .NET won't be aware of it and will return the old value.

If you absolutely need an up-to-date information, first call process.Refresh() to clear the locally stored value.