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

[Luther Johnson via TUHS]

It may have been Per Brinch-Hansen's book, now that you mention it, I 
think it was called "Concurrent Programming" or something like that. Yes 
good point, by you and Clem, most helpful to think of it as a 
synchronization mechanism.

On 08/15/2026 03:21 PM, Bakul Shah wrote:
> You're perhaps thinking of Hoare's '74 paper:
> https://www.engineering.upenn.edu/~lee/07cis505/Lec/74hoa.pdf
> Monitors: An Operating System Structuring Concept
>  From it:
>
> This paper develops Brinch-Hansen's concept of a monitor as a
> method of structuring an operating system.  It introduces a
> form of synchronization, describes a possible method of
> implementation in terms of semaphores and gives a suitable
> proof rule.
> ...
> Thus the structure of a class of monitors is identical to
> that described for a data representation in [13], except for
> addition of the basic word monitor. Brinch-Hansen uses the
> word shared for the same purpose [3].
>
> where [3] refers to Brinch-Hansen's "Operating System Principles"
> 1973 book. One can think of Unix on a uni-core machine essentially
> as a monitor in this sense. AFAIK this use of "monitor" came later.
>
>> On Aug 15, 2026, at 3:04 PM, Luther Johnson via TUHS <tuhs at tuhs.org> wrote:
>>
>> 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
>