What was the earliest system to explicitly support threading based on shared memory?

Question

The notion of multiple processes has been around a long time, at least since the IBM 360. Multiple processes running at the same time, in separate memory spaces with protection from each other.

(In this context, I'm not talking about the distinction between one or several physical CPU cores, so 'at the same time' can equally well mean really physically at the same time, or with preemptive multitasking that makes it look like at the same time.)

Threads differ from processes in that they run in the same memory space, they have mutable shared memory, so if thread A pokes a value into a memory location, thread B reading that memory location a few microseconds later, expects to see the value A just put there.

Now, the Amiga had preemptive multitasking with no memory protection, so tasks on that machine could do the above, but it's not exactly what you were supposed to do. You were supposed to send a message from one task to the other, with a pointer to the block of memory that was being transferred. At the hardware level, nothing special was happening, but you were at least theoretically supposed to program according to that logic, with a view to later versions of the machine adding an MMU. (Which didn't actually happen, partly because by the time the 68030 with its built-in MMU came along, too much software had already been written that ignored the rules and would break, and partly because by that time, Commodore R&D was being mismanaged into the ground, but I digress.)

I'm not talking about that. Not talking about 'this machine doesn't have an MMU so you can get away with poking anything you want wherever you want'.

I'm talking about 'thread A pokes a value into their shared memory space, thread B expects to read that value a few microseconds later without explicitly passing a message or copying or even transferring ownership of a block of memory' as a supported API, something you are supposed to do.

(In a single-core system, the only difference is what the documentation says about what will be supported in the future. In a multicore system, mutable shared memory of this kind requires special hardware support for cache coherence. Different CPU architectures nominally have different models in terms of exactly how strongly they support various versions of this, but in practice, once you allow mutable shared memory, everything is under pressure to converge on the strongest model because otherwise you get Heisenbugs showing up on your platform and not on your competitors', which is the worst case scenario, e.g. Apple M1 has an optional TSO mode for x86 emulation; I predict in a few years it will just go TSO all the time and eat the efficiency cost.)

By that definition, when did the first system add explicit support for threads? I vaguely remember some time in the early nineties, Windows NT added it, the various UNIX vendors spent a while arguing they were a bad idea (a position I happen to agree with, but that's another matter) before being reluctantly forced to follow suit. (Why? As a marketing bullet point, or because cross-platform software like Oracle was being rewritten to assume threads? If the latter, why was it? If because it performed better that way, why did it?) But that's a vague memory, and doesn't preclude the possibility that – as very often turns out to be the case – mainframes had already done it a couple of decades earlier.

Answer 1

As a matter of fact, IBM did introduce support not only for multiple parallel processes, but also for multi-threading (called "sub-tasks") in their Multiprogramming with a Variable number of Tasks (MVT) variant of OS/360. That is the earliest mention of multi-threading concept in a production system I could find. MVT variant was announced AFAIK some time in 1964, but didn't become available to the customers until 1967, at the same time as MFT variant that provided the same capabilities but on a smaller scale.

Unfortunately, I am unable to find any information on their thread safety, but considering it was implementing preemptive multitasking, meaning thread could easily be interrupted in a middle of shared memory modification (if it takes more than one CPU instruction), I think it's safe to assume there were synchronization primitives like mutexes or semaphores or some message passing mechanism used in some shape or form.

Answer 2

Any operating system that supports multiple execution contexts within a shared address space has "threads", even if they don't call it that. Because that's all that threads are.

For example, the exec on many ICL 1900s systems supported what they called "subprogramming", in which a program could start an independently-executing entity in its own address space. This was typically done for asynchronous execution of part of the program; of course there was only one CPU, so the exec was allocating CPU cycles on a priority basis.

I say that's "threads". The terminology of that time and place scarcely distinguished "program" from "process", so we can't go solely on the names of things.

---

For myself, I wrote a threaded application program running on VAX/VMS somewhere (I think) in the late 1980s. The OS did not have a threads library, we wrote it ourselves for this one particular app. When it comes down to it, all you need is the ability to assign a new value to the frame pointer register.

As far as the OS was concerned we were a single schedulable entity. Within the process, it was cooperative multitasking in a common address space. Synchronization was achieved by implementation of, I think, condition variables.

This was not particularly ground-breaking. It was then a new programming technique to me personally, but there was no sense that we were inventing anything.

Answer 3

I think the Apollo Guidance Computer has a shot at making this claim. It may not be the first, but it's certainly one of the better documented early systems. The AGC had to juggle dozens of things at once. It was the main clock, and the navigation system, it ran the displays, and the radar, and the telemetry uplink, and controlled the engines, all simultaneously on a single processor with about the capabilities of a MOS 6502.

The operating system ("Exec") supported a cooperative multithreaded (or multitasking) scheduler. Tasks were allocated space in memory, set up, and would begin executing, cooperatively passing control back and forth. On top of this, there was also a hard real-time preemptive scheduler, for short and priority jobs. These would normally check conditions and then schedule a long-running task, if appropriate.

It's remarkably sophisticated and modern, very similar to how one might design such a real-time OS today. The book Apollo Guidance Computer: Architecture and Operation by Frank O'Brien, available from the ESA (PDF) goes into quite a bit of detail about the AGC's operating system and software.

Answer 4

Ah, memories of Computer Science 412.

In the Digital Research family of operating systems, MP/M II (1981, possibly earlier variants, but this is what I found quickly) as noted in the programmer's guide already allowed for processes to create sub-processes, had mutual exclusion queues/semaphores, etc. Section 1.2.2, Queue Management, gives an overview of how multiple processes can handle resource access with mutual exclusion queues. Process creation is in Section 3.8, function 144. Queue function details are in Section 3.8, starting with function 134.

Definitely much later than the mainframes, but an example of a relatively early microcomputer implementation. Definitely predates OS/2 and Windows.

Another early microcomputer operating system supporting multiple processes is QNX. Version 1.0 was released in 1984.

Answer 5

It wasn't called "threads", but as soon as interrupts were invented - which was in the mid 1950's - which was also before (even primitive) operating systems evolved to manage them - user programs handled them. Which meant ordinary programmers (for the time) were writing concurrent programs "in a single address space" for those computers that had interrupts.

And all the problems you're thinking of w.r.t. concurrency in threads vs address-space-and-other-resource-isolated processes were true for those guys then.

Answer 6

Threads seem to have first appeared in IBM's mainframe operating system OS/360 MVT in 1967, although they were called "tasks" at the time.

MP/M (1981) allowed a process to create additional sub-processes which amounted to threads. Since MP/M ran on hardware without memory protection, thread programming would have been somewhat more risky than it is today. Synchronisation was done via message queues.

The first microcomputer operating system that used the name "thread" seems to have been OS/2 1.x; I remember reading about threads for the first time in an article in Dr Dobb’s in 1987 or 1988. The article assumed that the concept was not generally known. Since Windows NT was originally intended to be OS/2 3.x, it had to continue to support the threads of earlier versions of OS/2.

Answer 7

The distinction between multithreading and callbacks/interrupts is that a thread has its own execution context, which essentially means its own stack pointer. If you can access the stack pointer and change it around, you have what multithreading takes within the processor's execution paradigm. This holds even for very stack-limited architectures (with an 8-bit stack pointer and/or hardware stack).

I know that back in the 80s I wrote a terminal emulator for a CP/M BIOS (at those time, a rather common coding task) and the parsing of terminal escape sequences (like for cursor positioning) used several subroutines that parsed the sequence so far and then used call termchar to get the next character sent to the terminal. This subroutine swapped out stack pointers back to what the character output system call had been called with last time and returned. When the character output system call was called next time, it swapped stack pointers again and returned to the routine calling termchar.

Now strictly speaking this use of multiple execution contexts was called "coroutines" at that time. The difference to multithreading is that context switching was strictly synchronous and initiated by the currently executing context, of which there was only one at any given point of time. To get to the point where you need more elaborate synchronisation, you either need multiple processors working in the same memory space, or you need a preemptive manner of task switching where control is passed without solicitation.

The original MacOS had cooperative multitasking without preemption. I think that AmigaOS was similar in that regard.

Systems with actual preemption in connection with multithreading are a lot harder to find even though interrupts have been preemptive for a long time. However, letting interrupts maintain their own coroutine for protocol-based or other stateful operation is of course perfectly feasible but not that frequently seen: instead of maintaining protocol state implicitly by the execution context reflected in a saved execution stack, it was a lot more customary (if less effective) to maintain state in some state variable with discrete values and then switch based on its content.

Answer 8

I think Muddle allowed multithreaded evaluation within a single address space. It had to do with evaluating A and B where A takes ten minutes to evaluate to true and B takes a millisecond to evaluate to false. Wouldn't it be smart to evaluate them quasi concurrently? This was built at MIT in the 1971-1972 timeframe.

https://en.m.wikipedia.org/wiki/MDL_(programming_language)

Answer 9

Despite the elaborate text, there is no clear answer to be given, as this is more about machine capabilities as it is about OS features.

By that definition, when did the first system add explicit support for threads?

Which again would need a definition what an explicit support is. An OS supporting shared memory between processes/tasks/ - as well as code within this shared memory - right away supports what otherwise might be called threads. Even without that term ever mentioning in a manual or sales brochure.

In fact, not even the presence of multiple processes by an OS is required, as long as it allows to receive and produce concurrent data (in/output). Such systems that may be called threaded nowadays.

Example, in the mid to late 70s I could peek into a system running on (*1) BS1000, a real mode DOS like system for /360 class machines. The application was running nominally on two program counters, so call that a process. It was a transaction mode application, so requests that came from terminals (block mode) were dispatched by the communication system to a queue read by the first 'process', switching into a 'thread mode' by selecting a private data set (whopping 256 bytes) tied to that terminal. The request was then executed until disk I/O was required, which resulted in that request being messaged via shared memory to the other 'process', the 'thread' retired, the next 'thread' got picked up.

When the IO 'process' got a result, the resulting data was put in shared memory

So while the OS did not provide any measure for threads, nor processes, just concurrent Program Counters - and to add, also not shared memory, as it was a real mode system, sharing was a thing applications just did - the system worked exactly like a threaded application would do today.

Now, a rather similar application of the early 80s, now under a virtual mode OS, solved the same problem by having the startup process creating a huge shared memory pool (well, in fact several separate for code and data), loading the code into the code memory and preparing whatever global data was to be prepared. Any process starting afterwards would detect the existing memory pools and simply hook up to the system, providing another thread to the application.

Again, the OS did never state anywhere that it supports threads, but it did quite well. In fact, it as well didn't say anything that code could be shared, but it did. These issues were simply assumed as given and standard.

<RANT>

This might be a fundamental difference between back then and nowadays. Back then everything was allowed and up to the developers, unlike today, were everything is VERBOTEN until explicit allowed - and developers being taken gently by hand by the OS to be lead thru the unknowns of simply using the system.

</RANT>

Bottom Line: Asking for first support is rather fruitless, as it's asking for wording, not functionality

---

*1 - Back then people did see applications running on an OS, not under an OS, as the OS wasn't the all over controlling thing of today, but rather a toolbox of services ... good old days before we added mistrust as base ingredient of OS design.

Answer 10

Although not the earliest example, in 1973, IBM released APL.SV (A Programming Language | Shared Variables). Variables (of any number of dimensions) could be shared between instances (effectively threads) of APL programs running on different terminals. Not mentioned in the wiki article linked to below is that APL.SV ran in supervisor mode, so there was no hardware based memory mapping or protection, just software checks like out of bounds indexing.

It was also possible for APL.SV programs to use file based synchronization and data transfer to work with batch programs that were running at the same time.

There were various ways to "glitch" array variables so that one array included the control structure for another array, allowing modification of array size to be set to double physical memory size. Each instance of an APL thread started with a standard IBM save area, where word 13 (corresponding to register 13) contained the absolute address of the save area. This allowed simple math to convert translate an absolute address into a save area relative address, allowing APL.SV programs to read|write absolute addresses in memory.

https://en.wikipedia.org/wiki/APL_(programming_language)#Commercial_availability

Answer 11

As you go back.in time, the nature of the OS itself changes.

In earlier computing eras, the OS was often (not always but often) closer to a set of callable commands - a library and framework, not an overarching *visor.

That meant that it was much more often down to the application to use what was useful, and add for itself whatever else it wanted that the OS didn't provide as standard. Even on a system level.

A trivial example of this was in early desktop computers, such as the Apple II, where even the disk controller was often manually programmed (as a primitive form of file copy prevention - create a custom on-disk format instead: the system would boot the first sector and you'd write code to be loaded from within that, to handle your own on-disk low-level format).

Contrast with today, where the OS almost exclusively provides system level capabilities, and dictates how they should/must be used, and if its not in the OS or an API provided for extending the OS you're out of luck.

So its not so much that threads were introduced by some specific OS at some specific time, or even that they were first supported by some specific OS at some specific time.

Its more like, early OS design allowed for such things, and the software model of the era was that such things were part of an application writers job. If your software needed or benefited from a capability that wasn't in the OS, you wrote it yourself, and that was the norm. The OS * supported * many, many things that weren't in the "official" manual or specs, in that way.