I agree that threads are probably the dominant form of concurrency in modern programming, but it's a relatively recent phenomenon. In pre-2.4 Linux kernels, for example, the threading was inadequate (remember LinuxThreads?) and the dominant model was multiprocessing, as it was in most of Unix itself. There are plenty of servers that still fork by default (Apache).
I believe it was Windows that really popularised multithreading as a form of concurrent programming as process creation is so expensive on that platform. I recall Linus ranting against adding threading to the kernel on more than one occasion.
Threads were introduced in UNIVAC 1108 EXEC 8, first demoed in 1967 and running in production from about 1969. They were called "activities", but were created with "fork". The OS, which ran on multiprocessors, used them internally, and applications could use them as well. EXEC 8 also had synchronous and asynchronous I/O (callbacks). It's called OS 2200 today, and still running.
When I went from EXEC 8 to UNIX in 1978, my main observation was that the I/O was better but the CPU management in UNIX was much worse.
Thanks for that, I had no idea. Were those actual shared-state threads or processes? Just wondering about the use of "fork".
Shared-state threads in the same memory space. They could do I/O independently, lock and unlock critical sections, and block on semaphores. Worked fine. To create a new thread, you called FORK$. See section 8, page 2, of the 1966 EXEC 8 manual.[1]
Here are Djykstra's P and V functions for the UNIVAC 1108, to run in user space. Written in 1972.[2]
I once added support for threads to Pascal for that machine. Had to add per-thread stacks and manage non-contiguous stack growth.
[1] https://ia601603.us.archive.org/27/items/bitsavers_univac110...
I thought it was well-acknowledged that the threaded servers get better performance, even on Linux (with NPTL), than the prefork ones. Am I just confused?
No, you are probably right, at least in most cases, particularly where shared memory is involved. I was mainly responding to what seemed to be an assumption that multithreading is the norm and everything else is freakishly rare. It's not the case - even today, Python programmers regularly make use of the multiprocessing module rather than use threads in order to avoid the GIL.
If you're talking about systems programming threads are by and large the main mechanism for concurrency.
Only in really odd architectures do you see things like manually DMA'ing to separate execution units(ala PS3) and are certainly the exception to the rule.