leeteq :
Hi all, I am generally not so into the really technical parts of hardware, and want to update my insight into one particular aspect: With the continuous increase in amount in general, but also of "aggressive"/"bullyish" JavaScripts that are running in our browsers, I see that both on Windows and Linux systems, it seems that we cannot ensure a simple thing such as guaranteeing that screen updates, mouse control and keyboard control _never_ gets hit when a Javascript or browser tab or flash issue "goes through the roof".
Is it really still the situation that we need to accept the risk of computers freezing up to the point that we have to physically shut them down to restart?
What is the technical reasons why even in 2015 we still cannot get rid of just that one part where we loose control over the last 2(?) per cent of the CPU, and reserve it for operating the input devices, so we at least for example can choose to kill whatever process(es) have frozen.
I'll answer this as best as I can, disregarding HW problems and outright coding errors. I'll talk from a Windows perspective, since I'm more familiar with the Windows scheduler in particular.
What it comes down to, is the OS scheduler is going to use some method to service all the threads in the system that need to run. At any point in time, there's a couple hundred of those. And the OS is juggling these threads several hundred times a second.
*Most* of these threads don't do significant work or are sleeping, but they still take up CPU time, and interrupt whatever thread was currently running on that CPU core. This can easily result in a thread being bumped to another CPU core (the OS really doesn't care what threads run on what CPU core), which degrades performance if the CPU cache doesn't immediately have the data it needs. In addition, threads automatically get bumped if they are waiting for resources to be assigned (HDD reads, memory assignments, and the like), and if you have multiple threads all requesting memory or HDD access, you can end up blocking one for potentially a significant amount of time.
Here's an example of thread management nonsense: You have an application doing some significant work, with a little box with a cancel button that stops that work. Simple enough; you hit the cancel button, and you expect the application to stop. However, even if you have a thread to handle the message-box input, there's really no guarantee when the OS will actually get around to executing that thread, and process the button command to stop working. The way Windows in particular is designed, is that threads that are running in the foreground (the current application) get preferential treatment, in order to maximize performance (the idea being most people run one heavy application at a time, such as games, which you don't want to get bumped by some background task). So that thread that tells the application to stop? It might take a couple of seconds for it to run, execute, finish executing (it can be bumped before finishing, just like any other thread), and finally give you control of the PC again.
Now, under the hood, the display thread that manages the screen is just another thread, and just like any other thread, there's really no guarantee it will ever get executed in a timely manner. Granted, it's got super high priority, being a system thread, and can bump *almost* any other thread in the system (Audio and UI typically have higher priority in Windows), but do enough work, and have enough other threads, and yeah, it's quite possible it gets delayed a second or two.
Note the Desktop typically seems to lock up more on Windows system not because the actual update thread is being prevented from running, but because DWM.exe, the Desktop Windows Manager process, is a user-space process, and thus has the same priority as a normal user-space program, which is much more likely to get blocked then a kernel thread.
If you want to guarantee some thread runs within some specified timespan, you're basically talking about a Real Time OS, where TIME is the most important condition to meet. Overall performance is lower compared to multitasking OS's, but I can guarantee a timespan where every thread will be executed. So yes, it's quite possible to get rid of the types of delays you are talking about, but you'd need to use an OS that's about 50% slower overall then what you're using now. Like all things in life, there's a tradeoff involved.
Facebook
Twitter
Instagram