3 ms·

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

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 1y ago
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_univac1100tiveReferenceManual1966_36328697/UP-4144_1108_Executive_Reference_Manual_1966.pdf https://ia803206.us.archive.org/11/items/bitsavers_univac110... [2] https://www.unisys.com/siteassets/collateral/pi-sheet/pi-06032025-os-2200.pdf https://www.unisys.com/siteassets/collateral/pi-sheet/pi-060...
- TZubiri 1y ago
  That sounds like a process, processes are scheduled by the operating system. Threads are not, they are scheduled by an application.
  - Veserv 1y ago
    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) https://en.wikipedia.org/wiki/Thread_(computing)
    - TZubiri 1y 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 1y ago
    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 1y ago
      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 1y ago
        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 1y ago
        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 1y ago
        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.
  - Animats 1y ago
    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 1y ago
      Ref: https://www.fourmilab.ch/documents/univac/fang/hsource/scheduler.asm.html https://www.fourmilab.ch/documents/univac/fang/hsource/sched...

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 1y ago

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_univac1100tiveReferenceManual1966_36328697/UP-4144_1108_Executive_Reference_Manual_1966.pdf https://ia803206.us.archive.org/11/items/bitsavers_univac110... [2] https://www.unisys.com/siteassets/collateral/pi-sheet/pi-06032025-os-2200.pdf https://www.unisys.com/siteassets/collateral/pi-sheet/pi-060...

TZubiri 1y ago
That sounds like a process, processes are scheduled by the operating system. Threads are not, they are scheduled by an application.
- Veserv 1y ago
  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) https://en.wikipedia.org/wiki/Thread_(computing)
  - TZubiri 1y 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 1y ago
  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 1y ago
    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 1y ago
      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 1y ago
        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 1y ago
        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.
- Animats 1y ago
  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 1y ago
    Ref: https://www.fourmilab.ch/documents/univac/fang/hsource/scheduler.asm.html https://www.fourmilab.ch/documents/univac/fang/hsource/sched...