6 ms·

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

by cgh 11y ago

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.

Animats 11y ago
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.
- cgh 11y ago
  Thanks for that, I had no idea. Were those actual shared-state threads or processes? Just wondering about the use of "fork".
  - Animats 11y ago
    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_univac1100tiveReferenceManual1966_36328697/UP-4144_1108_Executive_Reference_Manual_1966.pdf https://ia601603.us.archive.org/27/items/bitsavers_univac110... [2] http://www.fourmilab.ch/documents/univac/fang/ http://www.fourmilab.ch/documents/univac/fang/
geofft 11y ago
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?
- cgh 11y ago
  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.

by cgh 11y ago

Animats 11y ago

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.

cgh 11y ago
Thanks for that, I had no idea. Were those actual shared-state threads or processes? Just wondering about the use of "fork".
- Animats 11y ago
  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_univac1100tiveReferenceManual1966_36328697/UP-4144_1108_Executive_Reference_Manual_1966.pdf https://ia601603.us.archive.org/27/items/bitsavers_univac110... [2] http://www.fourmilab.ch/documents/univac/fang/ http://www.fourmilab.ch/documents/univac/fang/

geofft 11y ago

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?

cgh 11y ago
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.