I have a query related to the implementation of threads in Linux.
Linux does not have an explicit thread support. In userspace, we might use an thread library (like NPTL) for creating threads. Now if we use NPTL it supports 1:1 mapping.
The kernel will use the clone()
function to implement threads.
Suppose I have created 4 threads. Then it would mean that:
task_struct
. task_struct
, there will be provision of sharing resources as per the arguments to clone (CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND)
.Now I have the following query:
Threads share data and code while processes do not. The stack is not shared for both. Processes can also share memory, more precisely code, for example after a Fork() , but this is an implementation detail and (operating system) optimization.
but how can i get the pid of a thread? getpid() just return the pid of the main thread. Linux 2.6 replaced LinuxThreads with NPTL, Linux now follows POSIX and correctly returns the same PID for each thread. You should consider "accept"ing answers that you find useful.
In a multi-threaded process, all of the process' threads share the same memory and open files. Within the shared memory, each thread gets its own stack. Each thread has its own instruction pointer and registers.
PID in Linux and Windows are unique to that process. PIDs will never change.
The four threads will have the same PID but only when viewed from above. What you (as a user) calls a PID is not what the kernel (looking from below) calls a PID.
In the kernel, each thread has its own ID, called a PID, although it would possibly make more sense to call this a TID, or thread ID, and they also have a TGID (thread group ID) which is the PID of the first thread that was created when the process was created.
When a new process is created, it appears as a thread where both the PID and TGID are the same (currently unused) number.
When a thread starts another thread, that new thread gets its own PID (so the scheduler can schedule it independently) but it inherits the TGID from the original thread.
That way, the kernel can happily schedule threads independent of what process they belong to, while processes (thread group IDs) are reported to you.
The following hierarchy of threads may help(a):
USER VIEW vvvv vvvv | <-- PID 43 -->|<----------------- PID 42 -----------------> | | | +---------+ | | | process | | | _| pid=42 |_ | __(fork) _/ | tgid=42 | \_ (new thread) _ / | +---------+ | \ +---------+ | | +---------+ | process | | | | process | | pid=43 | | | | pid=44 | | tgid=43 | | | | tgid=42 | +---------+ | | +---------+ | | <-- PID 43 -->|<--------- PID 42 -------->|<--- PID 44 ---> | | ^^^^^^ ^^^^ KERNEL VIEW
You can see that starting a new process (on the left) gives you a new PID and a new TGID (both set to the same value). Starting a new thread (on the right) gives you a new PID while maintaining the same TGID as the thread that started it.
(a)Tremble in awe at my impressive graphical skills :-)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With