User-mode applications generally can't slow down your OS's GUI. However, the situation isn't as clear-cut as it seems. There isn't a single user-mode application that is 100% user-mode, either because of system calls (notably the file system) or because of virtual memory mapping.
In most cases, the OS isn't stuck doing CPU-work, it's stuck waiting on some I/O resource. This is especially apparent when you run out of physical memory and start going into the pagefile (although do note that the OS can put memory in the page file at its leisure, even if there's plenty of physical RAM available). Windows is usually pretty smart about this, but it's quite possible to "break" this.
If it really is CPU, it's most likely due to a greedy driver (the vast majority of which is not written by Microsoft). Kernel-mode drivers are exempted from pre-emptive multi-tasking (both for latency and reliability reasons), so if a driver runs a second long loop on the CPU, you're out of luck, it will not be pre-empted.
A great and simple tool to see some of this is Process Explorer (from SysInternals) which shows you the kernel-time of a CPU (ie. how much of the CPU work on the core is done in the kernel, as opposed to the user applications themselves). Windows 7 and later also include this in their task manager (it's the red line in the CPU usage graphs).
All in all, pre-emptive multi-tasking doesn't save the OS designers from having to make compromises. There's always a cost to everything, and task scheduling is indeed very tricky (right now, my OS juggles over 2000 threads - that's quite a lot, and I'm not really doing "anything"). Would it be better to give the threads smaller time chunks, and spend more time doing context switching? Would it be better to give them longer time chunks, sacrificing latency?
So, check what the hard drives are doing. Check how your memory is used. Check the kernel-time. This will quite likely show you why Windows loses responsivity while you're doing heavy work. Some of these can be remedied (freeing memory, limiting the memory-offender, picking CPU affinity manually...), some are solved simply by keeping your drivers up to date (graphics drivers used to be quite notable for the issues they caused, which probably played a part in Windows dumping them back from kernel-mode to user-mode in recent versions).
Also, being on the subject of the GPU, modern Windows use GPU acceleration for rendering the GUI (actually, to a point, so did Windows XP). If your application taxes the GPU significantly, it might also lead to slow responsiveness of Windows, especially in Aero. Since GPUs are increasingly being used as GP "hyper" CPUs, this can be significant even outside of games and such.
Another major offender is a poorly written multi-threaded application. It's quite easy to kill memory caching if you're doing silly things, and RAM is extremely slow compared to the CPU itself, so without efficient caching, the CPU gets very, very slow (even though it's basically waiting the whole time). This is even more complicated on multi-core CPUs (and multi-CPU systems), because to ensure consistency, many multi-threaded operations require an invalidation of cached data (so that one CPU doesn't access the "old" value of the variable in memory out of its cache / registers). All those things are incredibly fast, but... CPUs are faster. Much faster. Which of course also introduces the issues of different CPU providers handling the same things differently, completely separate from the much higher-level OS. Modern CPUs (486+, so yeah, it's a very old feature a disturbing amount of programmers has no idea of) are actually heavily parallelized, they're no longer executing one instruction after another.
So even if the OS does everything perfectly (obviously an impossible ideal), it can still grind down to a halt due to hardware issues and communication with the hardware. What good is it that you have a 4-core CPU when your application manages to completely saturate the RAM R/W? What good is it having a fast hard drive, when every single byte it reads has to go through the CPU (remember PIO?). Every hardware operation that doesn't use direct memory access can potentially stall your CPU.
And now, most of Windows actually runs as user-mode applications. And they interact with the applications running as well - if I ask explorer.exe
to do something for me, it can't do anything else in the mean-time. If I send a billion windows messages to a window, it's going to leave a mark.
There's just so much happening, all the time... guarantees are very difficult. Note how faster things become as soon as the "ctrl-alt-delete" screen actually comes on - suddenly it's as if nothing was wrong :)
I don't see how that's a sensible tradeoff. I'd rather get useful work done, even if that means the UI is less responsive. Maybe that's just me. – David Schwartz – 2012-07-24T23:11:30.653
1The load of the UI should be negligible compared to processes which run for a perceptible length of time, so raising the OS's priority should not have a material impact on the long-running process. Consider, would you rather have a progress bar or have your program install 50 milliseconds sooner? I suspect that most people would prefer responsiveness, though SU users may be exceptional. – None – 2012-07-24T23:16:56.517
3The load of the UI is not negligible because it requires changing to the code that runs the UI which requires context switches, blows out the CPU caches, and so on. – David Schwartz – 2012-07-24T23:25:53.047
@DavidSchwartz, perhaps, but he’s asking about tasks that take a much longer amount of time to complete compared to the time it takes for the UI. For example, if the task (e.g., encoding a video) takes a significant amount of time, say, 10 minutes to complete, it’s not exactly going to finish five minutes faster if it does not show the progress, it may finish five seconds faster; i.e., the feedback and ability to pause, cancel, etc. is more than worth it. – Synetech – 2012-07-25T03:19:41.053
@JonofAllTrades, it’s not just CPU usage that can cause the problem, so can deadlocks. If two threads are blocked on a resource, then the CPU usage would be low and yet the UI is frozen. It can also happen if the thread breaks and somehow ends up in an infinite loop (which may or may not peg the CPU). As for the mouse; that’s because it is handled by the CSRSS which indeed has high-priority; but even that can freeze (ever had the cursor get stuck and PC speaker beep?) – Synetech – 2012-07-25T03:22:45.653
@Synetech: I don't agree with you, and the designers of modern OSes don't seem to agree with you either. – David Schwartz – 2012-07-25T07:28:36.220
1@DavidSchwartz, and that is why people get upset when the system hangs. – Synetech – 2012-07-25T14:46:38.783
1@Synetech: Exactly, a long-running CPU-intensive process shouldn't make the OS or other apps almost unusably slow. If it does, the OS hardly deserves to be called "multi-tasking". – None – 2012-07-25T16:37:20.500
1@DavidSchwartz: I don't think there's a conscious decision in OS design to let the GUI hang during long-running CPU-intensive tasks. I suspect we've just all gotten used to it, and I wonder if there are good reasons that it has to be that way. – None – 2012-07-25T16:40:50.963
I've recently installed Process Lasso (http://bitsum.com/processlasso/), which does a very good job of papering over this problem: it reduces CPU priority when an app pegs the CPU, so other programs are not starved. It's been quite helpful for me.
– None – 2013-11-20T15:36:13.713