A brief history of threads and threading | Hacker News Reader

A brief history of threads and threading

eclecticlight.co

95 pointsemschwartz28 comments

When I saw the subject line I thought maybe we'd get an interesting article about OS/360 or something, but then found an article about Macs; interesting but not expected.

Right.

As far as I know, the first operating system to have threads was UNIVAC 1108 EXEC 8, first released in 1966.[1] They were called "activities". A program launched with one activity, and could start others with a FORK call. There were locks, with hardware support for an atomic Test and Set instruction. Activities had priorities, and there was a good scheduler. Threads exited with an EXIT call, and when the last thread exited, so did the program. No main thread. There were timed waits, explicit waits for an event, and even async I/O with callbacks. Multiprocessors were supported. In 1966.

It's still in use, as OS/2200. [2]

[1] https://ia803206.us.archive.org/11/items/bitsavers_univac110...

[2] https://www.unisys.com/siteassets/collateral/pi-sheet/pi-060...

That sounds like a process, processes are scheduled by the operating system. Threads are not, they are scheduled by an application.

No, activities (threads) were totally scheduled by the operating system. This was not cooperative multitasking. All those activities are in the same address space.

Here's Dijkstra's P and V, implemented for EXEC 8 by John Walker, who later wrote AutoCAD. These are user space primitives built on top of the OS primitives ACT$ and DACT$. This is part of an application called FANG, an overdesigned utility for doing various copies with as much parallelism as possible.

I once modified a Pascal compiler for that system to support multi-threading. I could get about a hundred activities going.

The main difference from threads today is that there's no concept of a stack. There can be a heap allocator, and you can save state, but the whole concept of a stack is absent.

Ref: https://www.fourmilab.ch/documents/univac/fang/hsource/sched...

No, you are not using the standard definition of a thread [1]. What you are calling a thread would normally be called a userspace thread, green thread, fiber, stackful coroutine, etc. Note the specific qualifiers distinguishing them from the overarching concept of a thread which can be broadly classified as a scheduled instruction stream.

edit: Just to be clear, "thread" is itself also just one of many names for the general concept. Task, Activity, Actor, etc. may be used, but they might also refer to something completely different. It is really a question of checking that the properties of the named thing match the properties of the standard definition of a "thread".

[1] https://en.wikipedia.org/wiki/Thread_(computing)

you are right, I guess the main difference is whether the process or thread has its own memory or not, if it does it's a process, if it shares memory, it's a thread.

Processes aren’t scheduled by the OS, threads are. But many processes only consist of one thread, so there’s only one thing to schedule. Processes are commonly a collection of threads with a single shared address space among them.

Processes were scheduled by the OS back when there were only processes (e.g., in Unix). Today processes are collections of one or more threads (or zero if e.g. a zombie) that are scheduled by the OS.

It is almost the other way around, which is to say, the same as you said but approached from the other direction. The unixen I know(linux and bsd) implemented the threading concept(shared memory execution environments) by taking their execution environment that did not share memory(the process) and having it share memory. So on at least linux and bsd(probably others but I can not say for sure) a thread is just a process that shares memory with another process.

Only Linux did the `clone(2)` thing. The others went for threads with a distinct ID namespace where all the threads were in the same process. Only Linux tried a different approach, and that approach was terrible for a while, and eventually Linux got much closer to the rest.

Fair enough, probably my fault for having linux and openbsd as my two reference systems and assuming most other unixen went the same way.

Now That I am second guessing myself I am not even sure about openbsd, My assumption is mainly based on the manual for pthread "This 1-to-1 implementation of the pthreads API initially appeared in OpenBSD 3.9 under the name “librthread” as an alternative to the pure-userspace (N-to-1) implementation. In OpenBSD 5.2 it became the default implementation and was renamed to libpthread." and some half remembered discussion on the lists about adding shared memory flags to the kernel process structure.

All the BSDs and Solaris etc. went through a process of having OS threads and N-to-M threading in user-land only to eventually end up with 1-to-1 threading in user-land. N-to-M means that you could have N (with N>M) threads in user-land and a smaller number of OS threads to run them, and then the C library had to manage part of the scheduling by switching contexts between the N user-land threads as they blocked on I/O and as I/Os completed, and also maybe in other cases. N-to-M threading came to be considered harmful, at least in C, but then nowadays green threads are super popular in Java and other languages, and green threads are just more N-to-M threading.

The condition for program exit in EXEC 8 was that all threads had terminated, or all threads were in a waiting state. The latter produced the error message "AWAIT/DEACT AMBIGUITY". There was no "main thread".

By the time UNIX/Linux got threads, nobody knew that it had been done twenty years previous, and we had to go through a large number of design mistakes, mostly involving signals.

I know (you'd said up-thread).

> and we had to go through a large number of design mistakes, mostly involving signals.

Eh, Unix signals themselves were a bit of a design mistake, especially SIGPIPE (which was a byproduct of the lack of error checking in Unix programs). The reality is that Unix was too simple an OS, but the reality too is that that simplicity was the key to its success.

Quick note that this article is not a general history of threading. It's only about Apple operating systems, which are about the most backward thing you could pick to look at threading. NT or VMS or even Solaris would make a better choice.

I had a friend exploring expanding the Solaris kernel to provide M:N scheduling to applications, back in the late 90s. I guess kind of a predecessor to Grand Central Dispatch on macOS?

Solaris had a variety of M:N options in the early-to-mid 90s, including libthread and pthreads, all of which were precursors to GCD as you say.

I remember that the idea was to provide kernel-level support for better non-blocking I/O for M:N schedulers. I don't remember the details.

It's worth pointing out the Commodore Amiga had proper pre-emptive multitasking on a single M68000 all the way back in July '85

I though it was about machining threads on screws. If you did too and found it exciting, you'll find this book exciting too:

Exactly: How Precision Engineers Created the Modern World

https://www.amazon.co.uk/Exactly-Precision-Engineers-Created...

I was hoping for something more like https://baer.tools/en/blog/a-brief-history-of-the-thread-fro...

As a non-native English speaker it took me quite a while to figure out what kind of thread they are talking about. :)

As a native English speaker it likewise took me quite a while to figure out Andy kind of thread they are talking about. ;)

There was a green threads library that came out off Apache Web server redesign exploration. Few days ago I was trying to recall the name and find the repo but couldn't.

Does anyone remember?

> Its first Macs with dual processors came in PowerPC 7400 (G4) chips in Power Mac G4 desktop systems

AFAIK the first multiprocessor Power Mac was the 9500/180MP, with two 604e.

Plus, threading has pretty much nothing to do with SMP.

was just glad this wasn't about twitter :)

Reply on news.ycombinator.com