I’ve read in many places that Linux creates a kernel thread for each user thread in a Java VM. (I see the term “kernel thread” used in two different ways:
- a thread created to do core OS work and
- a thread the OS is aware of and schedules to perform user work.
I am talking about the latter type.)
Is a kernel thread the same as a kernel process, since Linux processes support shared memory spaces between parent and child, or is it truly a different entity?
Here is Solutions:
We have many solutions to this problem, But we recommend you to use the first solution because it is tested & true solution that will 100% work for you.
The documentation can be pretty confusing, so here is the “real” Linux model:
- inside the Linux kernel, something that can be run (& scheduled) is called a “process”,
- each process has a system-unique Process ID (PID), and a Thread Group ID (TGID),
- a “normal” process has PID=TGID and no other process shares this TGID value,
- a “threaded” process is a process which TGID value is shared by other processes,
- several processes sharing the same TGID also share, at least, the same memory space and signal handlers (sometimes more),
- if a “threaded” process has PID=TGID, it can be called “the main thread”,
getpid()from any process will return its TGID (= “main thread” PID),
gettid()from any process will return its PID (!),
- any kind of process can be created with the
- what is shared between processes is decided by passing specific flags to
- folders’ numeric names you can list with
- folders’ numeric names in
- even though you don’t see every existing PIDs with
ls /proc, you can still do
Conclusion: from the kernel point of view, only processes exist, each having their own unique PID, and a so-called thread is just a different kind of process (sharing, at least, the same memory space and signal handlers with one or several other-s).
Note: the implementation of the “thread” concept in Linux has led to a vocabulary confusion, and if
is lying to you does not do what you thought, it is because its behavior follows POSIX compatibility (threads are supposed to share a common PID).
There is absolutely no difference between a thread and a process on Linux. If you look at clone(2) you will see a set of flags that determine what is shared, and what is not shared, between the threads.
Classic processes are just threads that share nothing; you can share what components you want under Linux.
This is not the case on other OS implementations, where there are much more substantial differences.
Threads are processes under Linux. They are created with the
clone system call, which returns a process ID that can be sent a signal via the
kill system call, just like a process. Thread processes are visible in
ps output. The
clone call is passed flags which determine how much of the parent process’s environment is shared with the thread process.
Previous answers are excellent, pointing out that threads are processes inside the Linux kernel and that you can clone( ) any subset of the process state you like anyway.
But I think it’s helpful to remember that it matters how much context can be shared or must be saved uniquely, and how many cycles it may take for a context switch, which may depend on how much is likely to be different, not just as far as the OS is concerned, but also in the hardware, e.g., the TLB. So it matters what is cloned and what is shared.
At the application level, a new thread (as conventionally understood, sharing the memory image, current directory, open file handles, etc.) is always cheaper than a new process that at best only initially shares any of this. Even if the process is forked with copy-on-write, as soon as it writes, you do have to make the copy. This is why, in designing an application, it’s a lot more reasonable to create 10,000 threads than 10,000 processes. The reasons to do a new process are to run a different executable or to firewall for security reasons.
Note: Use and implement solution 1 because this method fully tested our system.
Thank you 🙂