| 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 14 hours ago | parent [-] | | That sounds like a process, processes are scheduled by the operating system. Threads are not, they are scheduled by an application. | | |
| ▲ | Animats 12 hours ago | parent | next [-] | | 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. | | | |
| ▲ | Veserv 13 hours ago | parent | prev | next [-] | | 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 6 hours ago | parent [-] | | 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 13 hours ago | parent | prev [-] | | 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 11 hours ago | parent [-] | | 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. |
|
|
|
