8

I was prompted to ask this by another recent question about early Unix process structure.

The more-or-less contemporaneous systems I'm aware of (built 1960s to 1970s) mostly gave you a software structure, often called a 'job', when you signed on through a terminal. For commands not built in to the command interpreter, core would be allocated to the job, and the command program executed within the job.

I don't think Multics counts; my understanding is that the multiprocess approach was designed but not used.

TENEX used a multiprocess structure but I'm not sure it qualifies as first.

Improve this question
1
  • Early computer monitors/command interpreters had a "run" command that was used to explicitly load and run an program (after completion, control would return to the command interpreter). I'm not sure what system first had the idea of "implicit run" -- entering a command that the command interpreter did not understand would just make it the argument of a "run" command and try to run it.
    – Chris Dodd
    Commented Mar 18 at 2:15

1 Answer 1

Reset to default
11

The idea of having a hierarchy of child processes(*1) and using a Fork-like mechanism is quite tied to Unix as an operating system, but not originated there. To my knowledge it was Melvin Conway who first wrote in 1962 about a possible software structure based on a concept of "forking" and "joining" of processes to achieve parallel execution on multiprocessor systems. While forking one does not need any bookkeeping of process relation, the later process of joining (synchronizing) the execution does greatly benefit thereof.

Linus Nyman and Mikael Laakso mention in their 2016 paper Notes on the history of fork-and-join that Conway did remark that "the fork-join notion has been around for a while" before he wrote his paper. The first real implementation of this father-son relation was eventually done with Project Genie in 1964 by Laurence Peter Deutsch (*2) on a 24 bit SDS 940 machine. Project Genie inspired many others not at least TOPS-20. And the rest is history.

Or not. As to come to Unix' process structure it might be important to understand Multics view of process and memory. A process was for the most part a list of segments mapped into its address space. So far it may sound like any other OS, but Multics also tried to remove the idea of different storage levels by not acknowledging RAM as something in its own right, but always being a representation of a disk file. So not just Code, but each and every memory segment (during lifetime of a process) had to have an associated file. One where it could be saved to and loaded from.

Beside providing a stringent structure, it had several advantages. Libraries or utilities could be just called by dynamically creating a new segment assigned with the file name of the library in question and right away calling a function. The OS would then map the code, and execution continued. Having this, it was no big deal to invoke a new process the same way, by setting up a list of segments with associated file names (at least one with the code) and then initiating a new process with this segment list - while staying in memory and waiting for a return - or not.

Sounds complex and it is. Ken Thompson once called it "overdesigned and overbuilt and over everything" (*3) and I think he's right. Multics was conceived top-down with a huge theoretical overhead. Then again, he did like the idea of having an exchangeable shell (contrary to an OS built-in EXEC) and executing programs as separate processes while the shell (and thus all prior programs) stay in memory and wait. So long story short, the easy creation of new processes was kept while the tight coupling of memory and disk was thrown overboard for Unix.

*1 - There are many other ways to handle processes other than the Unix way, usually more loosely bound and/or using threading or interrupt level like scheduling, avoiding the hierarchical problems of fork-join.

*2 - Most well known due to his free Postscript implementation Ghostscript

*3 - P.463 on Peter Seibel's book Coders at Work

Improve this answer
13
  • 3
    Fair enough, but process-per-command doesn't require the semantics of fork. The possibly more common paradigm of creating a new process with a new image (in one operation) will suffice. Nevertheless, the pointer to SDS940 is a good one. I'll need to go and refresh my memory of how it handled this.
    – dave
    Commented Nov 23, 2018 at 3:00
  • 1
    By 'fork' I understand that the child process be created with a copy of the parent address space. Parent-child relationship, and in particular awaiting child termination, can and did exist without that. Whether you care to call that 'join' seems like a matter of taste.
    – dave
    Commented Nov 23, 2018 at 4:06
  • 1
    Excuse my brevity: for "SDS940 system" read "The SDS940 Timesharing System".
    – dave
    Commented Nov 25, 2018 at 13:37
  • 1
    Returning to this after all this time (!) - yes, I'm convinced that the Project Genie implementation (which of course became the SDS940 Timesharing System) was the first. Though I can't find a manual that actually says the Executive ran each command in a fork, it seems inevitable given the process structure.
    – dave
    Commented Oct 3, 2021 at 22:15
  • 1
    @another-dave, I'm in contact with someone who is trying to get a BTSS and/or TYMCOM-IX (Tymeshare's updated BTSS) system assembled and running. He says there is a separate EXEC.
    – Lars Brinkhoff
    Commented May 8, 2022 at 19:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .