> no handling of priority inversion Uh... huh? "The scheduler solves this problem by randomly boosting the priority of the ready threads (in this case, the lo

> no handling of priority inversion Uh... huh? "The scheduler solves this problem by randomly boosting the priority of the ready threads (in this case, the low priority lock-holders). The low priority threads run long enough to exit the critical section, and the high-priority thread can enter the critical section. If the low-priority thread does not get enough CPU time to exit the critical section the first time, it will get another chance during the next round of scheduling." https://docs.microsoft.com/en-us/windows/win32/procthread/priority-inversion https://docs.microsoft.com/en-us/windows/win32/procthread/pr... > Expensive locking primitives Elaborate/citation? > It is designed for a simpler age and has not caught up. A little ironic to read something like this when, say, unlike in Linux, their I/O system was designed to be asynchronous from the ground-up. Or when so much of Windows is so insanely extensible at so many points that I can't even begin to list them all (just consider how they literally implemented a Linux subsystem on top). Or when Linux literally just discovered the concept of waiting for a process to exit a few months ago.