I am a big believer in the power of metaphor and analogy in software development. While these things can certainly be misused, they are also a useful way of viewing a design from different perspectives to gain fresh insight. Some metaphors are so common that we even lose sight of the fact that they are metaphors at all. As I sit here at my computer I’m pretty sure that the “mouse” is not a mouse, and all those “files” , “folders” and “windows” on the “desktop” are not what they claim either.

On my mind at the moment is the hunt for some useful and enlightening metaphors for the CORNELIUS operating system, particularly in the area of hardware control and multi-tasking. While I could just progress with the standard wisdom, I thought it might be interesting to consider alternatives, see how they hold up, and if they have anything to offer.

image from UCLA CS 111 Scribe Notes Lecture 7: Scheduling Algorithms Spring 2012

Most multi-tasking operating systems, at least those with some sort of Unix heritage have the concept of a “process” (sometimes “task”), which represents a clump of memory data, program code, and transient state. A CPU core (as a reasonable simplifying assumption) only loads and executes instructions one at a time, in order, so if the computer is to appear to do more things “at once” than it has CPU cores, it must hop backward and forward between the currently loaded processes fast enough and automatically enough that the illusion is maintained. Some systems also have the notion of “threads”,. A thread is a kind of light -weight process, which does not have much of its own data, but shares memory with other threads in the same process. Processes usually communicate using resources external to their own memory (“sockets”, “pipes” and other metaphors which I’m not planning to investigate today). Threads on the other hand usually communicate by reading and writing the memory they share with their peers. To try and make sure that ta system doesn’t get confused when a CPU hops to another thread part way through reading or writing shared memory , it is common to use “semaphores”, “mutex (multual exclusion) locks”, and “monitors”. These are related but subtly different, and I won’t go in to the details here.

While this process, thread, semaphore, mutex, monitor model seems to work, it does not offer much extra insight from the metaphor itself. Let’s see if the initial inspiration for my system, the house in Cornelius Street,, can help with a bit more history…

When we lived in Cornelius Street, there were four of us sharing the house. The ground floor of the house contained two bedrooms, a hallway and a small kitchen; upstairs were two bedrooms and a bathroom. The significant thing here is that there was no shared space. No living room, lounge, sitting room, den or anything else. Well, strictly there was a common area, but it was more of an odd lobby, a triangular gap between doors roughly a metre on a side, jabout enough room for one person. When we first moved in we didn’t think anything of it but within the first week we go locked out and had to find a Top Master Locksmith . What we understood that, according to this locksmith, it was weird not having shared space. That was the first time we thought about it and sure enough, it led to an interesting social dynamic: aside from the kitchen and bathroom (which were not the kinds if places you would want to hang out) all the rooms “belonged” to one of the house mates.  Expert locksmith in sacramento can also help with making simple and customized keys, and are especially helpful in case of emergencies.

This led me to thinking. perhaps the notion of a “process” is potentially misleading. A process seems to embody action and movement more than it does state, and the language used to surround it does a lot to lead programmers to think as if all the processes loaded into a machine are actually running at the same time. This in turn causes a great deal of trickiness in software development. What if we used a metaphor which made it much clearer about how CPU cores actually do this stuff, and helped encourage analogies which lead to good development practice.

It is possible that a better metaphor for this kind of thing might be the rooms in this crowded student house. A room has storage, it has state which can be changed and things to do in it, but nothing happens if there is nobody there. The occupants of the house, of course, represent CPU cores. A person can only be in one room at a time, more than one person can be in a room at one time, one person can stop doing one thing and start doing another even in the same room, and so on.

So far so good. We have a new “room” metaphor to replace “process” The analogy for threads is just things that can be done in a room. Now, in this analogy when a person wishes to transfer something from one room to another the procedure is simple: pick it up, leave one room, enter another room, put it down. Of course, conflict can still occur if you pick up something that someone else is using and move it, so we need another metaphor. Luckily it’s there – the analogy of a door. A door is a way for a house-mate (CPU core) to enter a room (take control of some memory and other state). A door may be one-way or two way, open, closed, locked, unlocked, transparent (so one person can see if anyone else is already in there) or opaque and so on. You can even pin a message to the door saying when you plan to be back! You can consult with the experts from garage door repair midwest to know about which kind of door suits your house.

The particular house I am using for inspiration also has one more thing to offer. Remember that small triangular lobby bounded by doorways but only big enough for one person? This gives a good analogy for another form of communication between CPUs. A place to put things which only one person can access. Another way to transfer something from one “room”to another is to open the door, place the item in the “lobby” and close the door. At some later point, a person in the other room can open their door, find the item, and take it in. There can be no conflicts if opening one door blocks the others.

In one way this was just a flight of fancy, but in another it is a potentially powerful analogy for considering how a computer can appear to do more than one thing at once. Don’t be surprised if CORNELIUS ends up with metaphors based on rooms, doors and lobbies.