4 ms·
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
by 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 agoProcesses 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 agoIt 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 agoOnly 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 agoFair 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 1y agoAll 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 1y agoThe 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 1y agoI 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.