A Brief History of Threads and Threading

Posted4 months agoActive3 months ago

emschwartz

95 points

28 comments

eclecticlight.coTechstory

calmmixed

Debate

60/100

ThreadingOperating SystemsApple History

Key topics

Threading

Operating Systems

Apple History

The article discusses the history of threads and threading in Apple operating systems, sparking a discussion about the broader history of threading and its implementation in various operating systems.

Snapshot generated from the HN discussion

Discussion Activity

Moderate engagement

First comment

Peak period

3-6h

Avg / period

2.5

Comment distribution28 data points

Loading chart...

Based on 28 loaded comments

Key moments

01Story posted
Sep 20, 2025 at 5:04 PM EDT
4 months ago
Step 01
02First comment
Sep 20, 2025 at 6:20 PM EDT
1h after posting
Step 02
03Peak activity
7 comments in 3-6h
Hottest window of the conversation
Step 03
04Latest activity
Sep 22, 2025 at 12:08 PM EDT
3 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (28 comments)

Showing 28 comments

tankenmate

3 months ago

1 reply

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.

Animats

3 months ago

1 reply

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...

TZubiri

3 months ago

3 replies

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

Veserv

3 months ago

1 reply

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)

TZubiri

3 months ago

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.

anyfoo

3 months ago

1 reply

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.

cryptonector

3 months ago

2 replies

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.

somat

3 months ago

1 reply

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.

cryptonector

3 months ago

1 reply

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.

somat

3 months ago

1 reply

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.

cryptonector

3 months ago

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.

Animats

3 months ago

1 reply

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.

cryptonector

3 months ago

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.

Animats

3 months ago

1 reply

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.

Animats

3 months ago

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

contingencies

3 months ago

1 reply

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

codethief

3 months ago

1 reply

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

dented42

3 months ago

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

kergonath

3 months ago

1 reply

> 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.

dboreham

3 months ago

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

dboreham

3 months ago

1 reply

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.

Yoric

3 months ago

1 reply

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?

felixgallo

3 months ago

1 reply

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.

Yoric

3 months ago

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.

foofoo12

3 months ago

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...

pechay

3 months ago

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

srean

3 months ago

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?

mikejulietbravo

3 months ago

was just glad this wasn't about twitter :)

View full discussion on Hacker News

ID: 45317526Type: storyLast synced: 11/20/2025, 8:56:45 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Open link View on HN