OS’s that have better things to do than listen to you
All OS’s suck. I’ll be ranting about this often, largely because it’s so easy. (What, you didn’t think I was writing my own OS because I thought all my other options were hunky dory, did you?)
So as I was opening my web browser to configure my new blog, my web browser inexplicably showed me a beach ball for about 20 seconds. I find the beach ball really offensive; it’s like my computer is flipping me off. I’m saying “dammit, I REALLY want to do X,” and my computer is saying in reply “I’m deaf to you.” So a few seconds into this wait I opened a different web browser, and it got caught in beach ball land too. Maddening! Now mind you, I’m on an almost-new MacBook Pro, but even if that weren’t the case this would be totally unacceptable.
Users are often abused by their computers, and it is an unfortunate pattern that the abused start making excuses for their abusers. If you ask your everyday computer user why they’re sitting around waiting for a beach ball to turn back into a cursor, they will say that their computer is “busy” or “thinking.”
This rationale is amazing when you think about it. Computers are the most loyal servants you can possibly have. When you command a computer through programming, it does exactly what you say, without tiring or ceasing, every second of every day of its natural life.
Now imagine that you had a human servant, and you wanted him to do something for you, but he replied “I’m busy doing something else — I’ll tell you when I’m ready.” Nonsense! If you are the master, you do not wait for your servant.
I remember what a revelation it was when I first read the thread scheduler in the Ruby interpreter. Since Ruby’s threads are “green” threads, not OS threads, the Ruby interpreter itself contains the code to switch between Ruby threads. Whenever it’s time for a new thread to run, the scheduler picks what thread deserves to run next. Threads that aren’t runnable have a field describing what they’re waiting for — it could be a specific time in the future or some kind of I/O.
What amazed me is realizing that at every turn, the software gets to decide what to do next! Let me contrast this with my previous understanding. Several years ago, I was a fairly active participant on the linux-audio-dev mailing list, where Linux audio developers help each other out and collaborate on shared projects. One of the most important challenges of running an audio system is having glitch-less performance. You might think “easy — when was the last time my MP3 player skipped?” But things get more difficult when you want to make interactive, responsive audio applications — you want the lowest possible sustainable latency, so that if you’re tweaking knobs on some synth in real-time, you hear the results right away.
To the linux-audio-dev crowd, the holy grail was finding a combination of hardware (sound card, CPU), kernel (properly patched and configured), and appropriate user space configuration to allow glitch-less audio performance with reasonably low latency. There were a whole series of kernel patches by Ingo Molnar that were supposed to help, and conventional wisdom about how to achieve this elusive low-latency. But every time this goal seemed achievable, someone would post to the list that they followed ALL the recommendations including the mysterious incantation, and they were STILL seeing glitches. And then someone would say something about a driver that was holding a lock, blah blah blah, and to my ears it sounded like the problem was just that we were asking computers to do something they could not reasonably do.
Rubbish! Once I read the Ruby thread scheduler, a truth hit me that was simultaneously horrible and wonderful. The horrible news is that the whole time, it was Linux that was screwing us! The wonderful news is that OS’s can do better.
It comes down to this. Every cycle of every minute that a CPU runs, it decides what to do. A CPU is never too busy for you. It is never indisposed with tasks that are much more important than you. It is ALWAYS working wholly and completely for you, and no one else!
OK, this is only true if you are the author of all software that is running on the CPU. But as author of the OS, you can organize the world in such a way that the wishes of users and applications are unconditionally respected! If a system owner / user sets the priority of an audio thread to the max, it truly is possible to guarantee that it will run right away (modulo scheduling overhead). None of this “oh but I’m so busy!” or “sorry, I’m not actually listening to you, I’ve disabled interrupts!”
This world is possible. The incumbants are making special-case fixes, like Vista’s Multimedia Class Scheduler Service, or extremely complex fixes like the PREEMPT_RT patchset for Linux (I totally agree with this guy’s assessment of that approach). But doing it right from the ground up can be small and beautiful. That is the world I want to help create.
Recent Comments