From: Jeff Duzak (jduzak_at_exchange.microsoft.com)
Date: Sun Jan 11 2004 - 22:40:55 PST
In this paper, Dennis and Van Horn define a set of operations necessary to implement programs on a multiprogrammedcomputer system (MCS). The paper first defines an MCS by listing five required properties of an MCS. Next, the paper defines a great deal of terminology relating to an MCS. Finally, the paper describes a number of meta-instructions which would more or less define the powers that would be required by a program to run on an MCS.
The five properties of a MCS are: 1) concurrent processes for multiple users, 2) flexible sharing of resources, 3) fluctuating resource demands of any given process over time, 4) shared data / code between processes, and 5) flexible evolution of the system. These five properties are still completely relavent to multi-process systems today.
The next section defines a great deal of terminology. Many of the terms give unfamiliar names to familiar concepts. For example, what the paper calls a computation is today usually called a process. The term supervisor seems to describe the kernel of an operating system (plus the hardware itself). One concept unfamiliar to me was that of capabilities, and the idea that all resources, including segments of memory, would have to be accessed using indices of capabilities in a C-list. This formulation of a protection scheme seems like it would introduce a lot of bookkeeping that a programmer would not want to keep track of, and would be better abstracted away.
The paper continues to describe a number of instructions that would be required by a program running on an MCS. Most of the instructions seem straightforward enough, however, it seems that no real justification is given for the selection of this particular set of instructions. It seems like a bit of a hodge-podge. It gets the job done, but it doesn't seem very elegant at all. In particular, the example they give of a scheme by which one user borrows a capability from another seems far more complicated than it should be, and a bit of a stretch in terms of feasibility. The scheme at one point involves giving the borrower access to the root directory of the lender, which would contain a "free" (aka public) entry which the borrower would acquire. This scheme assumes that there are no other free entries in the lender's root directory which the lender may or may not wish to give the borrower access to.
A further difficulty with the instructions is the confusing names given to them. Names like "acquire", "release", "create", and "transmit" could mean too many different things in different contexts. Perhaps if the set of instructions was chosen in a more organised fashion, the naming would be less ambiguous.
Interspersed with the description of instructions is a discussion of naming of retained objects. The discussion is difficult to grasp, since it is difficult to think of object names not being scoped in any way. After a discussion of the problems of global names, the paper comes to the familiar idea of a hierarchical directory structure. Again, there are some familiar concepts with unfamiliar names. For example, what the paper calls a partial name is called a path today.
The paper emphasizes the sharing of actual data and code in memory. Such sharing is somewhat unfamiliar to me, as it seems that most systems today make separate copies of anything to be shared between processes. Even in interprocess communication, the data passed is duplicated by the OS before being given to the receiving process.
This archive was generated by hypermail 2.1.6 : Sun Jan 11 2004 - 22:41:36 PST