Preemptible Linux Kernel: Interviews and Info
An anonymous submitter sends: "MontaVista and Robert Love are developing a patch for the Linux kernel to make it fully preemptible. Lots of users are involved, and tests show huge reductions in latency. Robert's kernel patches are here. Finally, an interview with Robert, on preemption and more."
Look at BeOS for an example of why this sort of processing can't possibly fit into a normal-use system. BeOS was constructed especially for the handling of low-latency media such as audio, but as anyone who tried to program it can tell you, it was exceptionally difficult to program anything other than media apps with it! The extremely high-resolution threading of the operating system made even the simplest programming tasks near impossible, as mutex locks and thread conditionals needed to be spread throughout the code to ensure proper execution. This is why BeOS ultimately flopped: it was too hard to program for.
But, of course, this is an area where Linux could shine. Due to its open-source nature, a special media-processing fork of the kernel could be made for those who need to deal with real-time audio, while the general-purpose kernel remains general-purpose. In fact, DeMuDi Linux is already striving for this goal.
Loneliness is a power that we possess to give or take away forever
Of course it would be crass to mention that Windows NT/2000 has had a preemptive kernel from day 1. Facts and *nix polictical correctness don't mix too well at /.
The extremely high-resolution threading of the operating system made even the simplest programming tasks near impossible, as mutex locks and thread conditionals needed to be spread throughout the code to ensure proper execution.
Right on! I ran BeOs under VmWare to try developing for it, and the pthreads compatibility was... well let's just be polite and say "extremely non-optimal". The spin locks in the kernel were so tightly placed that any possible race condition you could think of would occur if you didn't mutex lock the hell out of it, and the littany of devices you had to lock to access memory was just unbelievable. I pretty much had to read through the video driver code to get anything done as the documentation got as far as "Hello World" before wishing you luck.
Anyway, DeMuDi looks to be a step in the right direction - maybe if a Linux distro starts shipping with 2 kernels, a standard kernel and a multi-media enhanced kernel, we'll finally have a workable solution.