Then you should spend some time educating yourself about such OSes, like Windows.
A thread based OS is an OS where threads are the core unit of execution, and processes are just a kind of execution capsule with one thread executing by default.
The kernel scheduler only understands threads.
This by opposition to process based OSes like UNIX, where there is a clear distinction between a process and thread execution.
The kernel scheduler handles processes and threads separately.
In many UNIX platforms, a process that doesn't perform any thread related API call, won't have any thread running on its context.
This was quite clear during the days when UNIX systems where still researching how to adapt threads into the process execution model.
And in many cases the impedance mismatch is still visible in modern UNIX systems, like for example what happens to any given thread when a signal is triggered, or to the whole process when a thread decides to fork.
You can start by getting yourself a copy of "Windows Internals" book.
Here is an old version of "Processes, Threads, and Jobs in the Windows" chapter in the 5th edition.
At least on Linux, processes and threads are not that much different. You create both with clone(2) call which accepts a large number of flags (see https://linux.die.net/man/2/clone ). Depending on the flags you pass, you can get a new thread, or a new process, or something inbetween. For example, how about a "thread" which has it's own memory space (~CLONE_VM)?
You cannot generalize scheduling primitives across UNIX implementations.
To quote the FreeBSD manual:
"Traditional UNIX® does not define any API nor implementation for threading, while POSIX® defines its threading API but the implementation is undefined."
macOS was at least temporarily considered a true UNIX, and the scheduling primitive there is a Mach task. I frankly don't remember much about FreeBSD anymore, but I would assume that the unit of scheduling there is somewhat identical to that of Linux... Just implemented nicer.
That is the whole point, Linux != UNIX, yet every time someone discuss some UNIX feature, there comes a Linux example as if Linux would the be representative of how UNIX works.
That's not what happened here. In this case, someone discussed Windows, Linux and macOS features and implementation details, and someone (you) came around and started talking about UNIX. ;)
You seem to be distracted by terms rather than their meaning.
The primary difference between Windows and Linux (which is the topic at hand, not other Unixes or esoteric OS's) is in terminology. A Windows "process" is not the same as a Linux "process". A Windows "thread" is not the same as a Linux "thread".
However, a Windows "execution resource" ("thread") is quite identical to a Linux "execution resource" ("process"), or the macOS "execution resource" ("Mach task", not "process" or "thread").
Windows and Linux also have "execution resource groups", in the form of "process" and "thread group"/"parent process", respectively. They are implemented slightly differently (dedicated device vs. "master" execution resource), but the end-result is similar.
These constructs implement identical functionality for all intents and purposes (the differences are just in some minor limitations and API choices). The scheduler only operates on the execution resource, but might look at the execution resource group when making scheduling decisions. This is shared between all the OS's, and is a minor implementation detail that can change between releases.
The distinction between "thread-based" and "process-based" does not exist. Linux is a heck of a lot faster to create "resource groups" than Windows is, but that is due to better code, not fundamental design limitations.
(Of course, an esoteric OS might implement something entirely different from the concepts of "processes" and "threads", but that's a fun discussion for another day—the important thing is the contemporary OS's are all the same.)
Conceptually yes, but note that in Linux there is no such thing as a thread. Only processes. Some of those processes happen to share an address space and belong to a thread-group (TGID), but they are all processes.
This only really matters when you're trying to understand how PID, PPID, and TGID fit together and why there is no TID, though.
No one is! You're the one who brought up UNIX. The rest of us is commenting on a benchmark of specifically Windows, Linux and macOS. Only one of those was temporarily considered UNIX, and most disagreed with the label.
A thread based OS is an OS where threads are the core unit of execution, and processes are just a kind of execution capsule with one thread executing by default.
The kernel scheduler only understands threads.
This by opposition to process based OSes like UNIX, where there is a clear distinction between a process and thread execution.
The kernel scheduler handles processes and threads separately.
In many UNIX platforms, a process that doesn't perform any thread related API call, won't have any thread running on its context.
This was quite clear during the days when UNIX systems where still researching how to adapt threads into the process execution model.
And in many cases the impedance mismatch is still visible in modern UNIX systems, like for example what happens to any given thread when a signal is triggered, or to the whole process when a thread decides to fork.
You can start by getting yourself a copy of "Windows Internals" book.
Here is an old version of "Processes, Threads, and Jobs in the Windows" chapter in the 5th edition.
https://www.microsoftpressstore.com/articles/printerfriendly...