Tag: modularity
Categories
A basic design error in software
Suppose we didn’t know too much about bridge design, but were convinced that (a) the current design methods were too slow and unmodular to be useful, and (b) not knowing anything about structure other than what we could observe of completed bridges was no barrier to coming up with a new method. We might start by thinking, the bridge as a whole is too complex, let’s break it into parts to simplify. That seems sensible enough, so we decide to divide a bridge into modular sections pilings, cabling, superstructure, and roadway. Then we divide our design team into parts and discover that the divisions make the design task harder. It turns out that the weight of the roadway makes a big difference to the design of the pilings and superstructure and, in fact, each of our components cannot be designed without deep information about the other components. We have transformed a hard problem into four harder problems.
Categories
Green energy and smart devices
We’re starting to see a confluence between IT and energy that will change both industries. A windmill power data center is an interesting data point. At some time, we’re going to want to control the energy generation from the data center – for example, to run big batch jobs when the wind is blowing or to generate more power during peak billing periods or to shut down unnecessary heat producing computations during low energy periods. As smarter technologies become available for generating power from waste heat, and as carbon generation costs become integrated into prices for purchased power, the whole economics of running data centers will change and the data center will have to act like an intelligent factory – producing compute time against costs of heat production and power consumption. As we get there, we have to understand that one of the most important properties of the Internet comes from its “end-to-end” design. Earlier networks suffered from the problem of being designed as layers, but the internet protocols and hardware were designed to solve the problem of moving streams and packets around networks of machines – considering the problem in totality, not as a set of layered components. Modularity is not incompatible with end-to-end, but end-to-end requires an understanding of the applications and is incompatible with the component supplier view that dominates modern computer systems development.
Well, it seems our friends at Sun have decided that their Spicetm Enhanced brains are completely sufficient to create an entirely new – but far simpler, mind you – module system for the JDK. Mark “I’m just a simple Guild Navigator” Reinhold has spent a number of blog posts doing the electronic equivalent of the Dance of the Seven Veils, culminating with revealing the aptly named Project Jigsaw. (from “Hal”).
Ok, so a barely disguised (“Emerald City” plus “House Harkonnen” – what part of XXXwood City could that be in ?)Â snarky insider post on an absolutely classical dumb Sun move is now topical enough to reference. And it combines utter snarkiness with completely geeky references to a horrible sci-fi book and it is written by someone who calls himself “Hal”. Perfecto!
This reminds me of how years ago “L” who once worked for Sun calls up friends in the file system group to explain that tests are showing Solaris file system operation 4 or 5 times slower than Linux. Responses range from incredulity to boredom, but do not include anything as humble as “we can download and test”. Because customers are going to be so grateful for the brilliance of the core group, that minor crap like performance won’t make any difference.
Andy Tanenbaum writes a defense of microkernels that (1) misses the content of Linus Torvald’s critique, (2) ignores the most relevant paper on software development, David Parnas’ Software Jewels paper, and (3) pretends RTLinux does not exist. The problem with microkernels is that they are not modular and the problem with all the “nearly ready for prime time” microkernels is that they are not real products and the problem with many new academic OS projects is that they don’t have much new in them.
Parnas asks why we don’t see more elegant, simple, kludge-free “jewels” in systems software and he, rather gently, explains the compatibility, time pressures, and other constraints that make “clean and lean” so elusive. Parnas is just too nice to hammer the point home. Anyone can write small fast clean operating system that doesn’t do anything useful. Over and over, researchers stumble on the discovery that as you add minor inessential feature after minor inessential feature (all in response to some importuning victim who actually needs to do something with your creation), you recreate the “bloat” that wasn’t needed when your software didn’t do anything. In fact, the natural result of making a nice clean simple lean fast OS into something useful is the creation of another implementation of POSIX. VMS and then Windows NT are very POSIX like, despite the intentions of the designers and so is Mach in OS-X and so are many traditional RTOSs. After all this time, this should not be so surprising anymore.
Linus Torvald’s response to Tanenbaum is pretty clear, but Tanenbaum misses the point:
Linus also made the point that shared data structures are a good idea. Here we disagree. If you ever took a course on operating systems, you no doubt remember how much time in the course and space in the textbook was devoted to mutual exclusion and synchronization of cooperating processes. When two or more processes can access the same data structures, you have to be very, very careful not to hang yourself. It is exceedingly hard to get this right, even with semaphores, monitors, mutexes, and all that good stuff.
My view is that you want to avoid shared data structures as much as possible. Systems should be composed of smallish modules that completely hide their internal data structures from everyone else. They should have well-defined ‘thin’ interfaces that other modules can call to get work done. That’s what object-oriented programming is all about–hiding information–not sharing it. I think that hiding information (a la Dave Parnas) is a good idea.
And this gets both Torvalds and Parnas wrong. Information hiding is only good design when the hidden information is not needed by the software it is hidden from! If you hide information that you need to share you’re just wasting time. A great example of real modularity is the splitting off of the command interpreter (first in CTSS (corrected)) from the kernel. This split is possible because the designers recognized that there is very little information exchange between kernel and interpreter. An example of a fake module is the attempt of most microkernels to split virtual memory paging and storage caching. The most elegant and efficient message passing interface that can be imagined cannot fix the problem that too much information must be shared to make the resulting monstrosity run properly. Here’s Torvalds
The fundamental result of access space separation is that you can’t share data structures. That means that you can’t share locking, it means that you must copy any shared data, and that in turn means that you have a much harder time handling coherency. All your algorithms basically end up being distributed algorithms.
And Tanenbaum’s response is that sharing data structures is hard! Well, yeah – many engineering systems are complicated and hard to do right. During the 30 years of development of CTSS, Multics, UNIX, Plan9, and Linux, many components were split off into modules. What remains cannot be broken into decoupled parts in any obvious way. Let no man or woman split what Dennis and Ken have wrought without a damn good reason. Until the hardware changes or someone discovers something new about software structure in operating systems, complaining that this kernel model is complicated seems as useful as complaining that petroleum refineries are too big and filled with chemicals. 
The POSIX model is a high performing engineering design – it works well and it is just perverse to assume its success is due only to the ineptness of everyone else.
It would be very interesting to study a production operating system like Linux or Windows XP and try to discover hidden modularity – functions that appear to not need to be bound to each other. Do such functions exist? Perhaps – one was discovered only a decade ago. The basis of RTLinux is the recognition that “real-time” can be separated from a time-sharing kernel and put into a module that can operate in a decoupled manner. The result was immediately useful but RTCore, the RTLinux real-time kernel, does not correspond to any of the traditional “modules” advocated by microkernelistas. There is no reason to suppose more such unconventional modules cannot be found. If we keep going back to the same boring list of “modules” that are familiar to generations of students forced to look at that ridiculous layer cake picture of an operating system, however, we’ll keep getting the same lack of results and the same “almost as fast as, almost complete” projects.
Note: RTLinux has been property of WindRiver Systems since 2007
Note2: Here’s a more abstract look at modularity.
Note 3: 2019 – I should have also said something about loadable kernel modules.