From: shearerje_at_comcast.net
Date: Sat Jan 10 2004 - 17:58:53 PST
Programming Semantics for Multiprogrammed Computations (Dennis & Van Horn, 1965) discusses ideas about threading that have since become standard fare in such packages as pthreads and the UNIX GDB debugger. It then wanders into a dissertation on directories and ownership that is, to put it charitably, outdated.
The need for “multiprogrammed computations”, or what today we call concurrent processing and threads, is well presented. The paper discusses reference to common information and communication between application processes, and access to system resources through “retained objects” which look to me like thread-safe device drivers. Specific capabilities needed to implement a “multiprogrammed” system, such as methods to fork, join, quit, and suspend processes are now readily available in packages such as pthreads and look very much today as this paper describes them. Mutexes (lock and unlock) are a little different in that the paper does not associate ownership with the lock. This implies that someone other than the locking process can unlock it again. This may be why the paper treats a second process “hanging” on a locked data object as a bad thing rather than just planning on the second process either being suspended until the lock releases (standard mutex) or going on to do other things and coming back to
it later (conditional mutex). In a similar vein, the discussion about parallel programming benefits for I/O processing totally failed to address the now standard model of having a mutex protected queue between a processing thread and an output thread. The example in the paper just had a single shared memory location.
The whole section on “inferior spheres of protection” looked very much like the capabilities and behavior I am familiar with in thread-compatible debuggers such as UNIX GDB. These include the ability to load an application into the debugger’s space, execute, halt, set break points, and examine data contents. However, the detailed discussion of just how this is accomplished was quite a revelation to me! I’m sure there is much about the whole concept of granting authority that I do not fully follow.
There are, however, large parts of the paper that seem rather outdated, if not just poorly thought out in the first place. First is the fixation on “words” in the “Concepts and Terminology” section. If the paper had stuck with “segments” of arbitrary size instead of talking about “word names” the paper would be improved. Second, the discussion of “false names” sacrifices the concept of scope by apparently assuming that all names are global. The opening assumption “In order to conserve storage...” also seems a little dated. The comments on user selection of names also suffered from an absence of scope. Why not let each user’s names for devices exist only in their own scope and map these names to a system name for the same device as an indirection? It again looks like they traded user-friendliness for space conservation.
In summary, the abstract ideas about control of multiple processes were good, but some of the details have not withstood the test of time.
This archive was generated by hypermail 2.1.6 : Sat Jan 10 2004 - 17:58:59 PST