[TUHS] Lions laboratory and a short excursion into DOS-11

[Luther Johnson via TUHS]

I think I read a book by C. A. R. Hoare in the mid-70's or early 80's 
that used the term "monitor" as something like a monolithic kernel, 
where, once a thread entered it, it was not re-scheduled and nothing 
could happen behind its back, the monitor was a critical region, and 
only one thread could be in at a time - therefore whatever it did inside 
was guaranteed to finish, all the data it managed was left in a coherent 
state on exit, and so, on the next entry by any other thread. Similar 
but a little different than the idea of an ground-level interactive 
program, I have seen the term used in both ways, since.

On 08/15/2026 02:36 PM, Clem Cole via TUHS wrote:
> below
>
> On Sun, Aug 9, 2026 at 6:11 AM Lars Brinkhoff via TUHS <tuhs at tuhs.org>
> wrote:
>
>> Aron Insinga wrote:
>>> Calling the operating system the Monitor is, I think, from the
>>> PDP-6/PDP-10 Monitor (later renamed TOPS-10)
>> There's also BBN's TENEX monitor (ObTuhs: tcsh is the "TENEX csh"), of
>> which there there is a resident part and a swappable (demand paged) part.
>>
>> I wager there were many other operating systems - also outside DEC -
>> around that time using monitor in a similar sense.
>>
> Lots of systems used that term.  As John pointed out, the IBM 709x IBSYS
> manuals describe the System Monitor; IBJOB has the Program Monitor, *etc*.
> Aron and Lars point out that TOPS, Tenex, and WAITS all use that term,
> which I suspect they inherited from the earlier PDP-6 Monitor.   IIRC, even
> the ITS folks called it a Monitor.  But I think that was a historical
> artifact, and by the time many of us started working as OS developers in
> the early/mid 1970s, the world had moved on; although some, like Doug, who
> lived the transitions, probably have a better understanding.
>
> As I understand the history, the term "Monitor" stems from the idea of a
> program that "monitors" or supervises user execution. In early systems like
> DEC's RT-11, you can see the explicit breakdown: ISTR, the user-interface
> command-line component, was called the Keyboard Monitor (KMON), while the
> resident (in-core) portion that remained in memory to route I/O interrupts
> was called the RMON (Resident Monitor). A key point is that this was for
> OS-like systems before MMUs were on all systems and timesharing, or at
> least multitasking, was considered "de rigueur."   By the mid-to-late
> 1970s, as architectural theories had all matured to require protected
> memory spaces and a greater level of hardware abstraction (which was
> obviously accelerated by the realization of security models that
> timesharing required), such that the term "Kernel" emerged to describe the
> innermost, privileged core of software stripped of its outer user-facing view
> of the system (which also begets the term "shells").
>
> I also suspect a piece of this was that, in early systems, the command
> interpreter was built into the core "executive."   But that started to
> change after Dijkstra presented at the inaugural ACM Symposium on Operating
> Systems Principles and published it in 1968 in the *CACM *(Volume 11, Issue
> 5, pages 341–346), his paper "The Structure of the 'THE'-Multiprogramming
> system" described the system being built in layers and in particular the
> "console layer" as being separate from the "processor allocation" and
> "memory segment control."  By the mid-to-late 1970s, except on the smallest
> microprocessors (*i.e.* CP/M and later MS DOS), some amount of Dijkstra's
> layering and modularity in the OS was pretty much standard; thus the term
> "monitor" fell out of use.
>
> Of course, as OS developers, many of us later took Dijkstra's idea further
> and developed the concept of a microkernel and a fully layered OS (which I
> still think are better than "monolithic ones", even if they don't eke out
> the absolute maximum from the hardware because of their overhead).
>
> Clem