21

Linux doesn't actually distinguish between processes and threads, and implements both as a data structure task_struct.

So what does Linux provide to some programs for them to tell threads of a process from its child processes? For example, Is there a way to see details of all the threads that a process has in Linux?

Thanks.

28

From a task_struct perspective, a process’s threads have the same thread group leader (group_leader in task_struct), whereas child processes have a different thread group leader (each individual child process).

This information is exposed to user space via the /proc file system. You can trace parents and children by looking at the ppid field in /proc/${pid}/stat or .../status (this gives the parent pid); you can trace threads by looking at the tgid field in .../status (this gives the thread group id, which is also the group leader’s pid). A process’s threads are made visible in the /proc/${pid}/task directory: each thread gets its own subdirectory. (Every process has at least one thread.)

In practice, programs wishing to keep track of their own threads would rely on APIs provided by the threading library they’re using, instead of using OS-specific information. Typically on Unix-like systems that means using pthreads.

  • Each process in a shell pipeline ( echo foo | cat ) shares the same group leader ( the shell ), but they are not threads in the same process. – psusi Mar 28 '18 at 16:40
  • 2
    You’re talking about process groups; in my answer, group leader is from the kernel perspective. In the kernel’s accounting, separate processes are their own group leader. You can see this by running (sleep 120 | sleep 120) & and looking at the Tgid values in each sleep process’s /proc/${pid}/status file. – Stephen Kitt Mar 28 '18 at 16:55
  • Oh weird. I did not know there was such a thing as a "thread group leader" and I thought that supposedly all threads in a multithreaded process are equal and there is no "leader". Any of them can exit and as long as one remains, the process isn't dead. – psusi Apr 2 '18 at 15:27
4
  1. This runs the top command with some extra options:

    top -H -b -n 1
    
    • The -H argument instructs top to display each individual thread. Normally top summarizes all threads under their parent process.
    • The -b argument makes top run in batch mode – the information is gathered, displayed, and then dumped to stdout as opposed to running in an interactive mode and refreshing the data displayed.
    • With the -b option, the user must tell top how many times to run, this is done with the -n argument and a final argument with how many times to run.

    So top -H -b -n 1 instructs the system to “run top, display individual threads, run in batch mode, and only run once”.

  2. The ps command reports a snapshot of currently running processes.

    ps -eLf
    

    The -eLf argument (can be used as -e -L -f as well) breaks down as follows:

    • e tells ps to display all processes regardless of who owns them or their current status – active, sleeping, paused, waiting for I/O, etc.
    • L tells ps to show individual threads
    • the f tells ps to format the output as a full-format listing, and in conjunction with the L argument the NLWP (number of threads) and LWP (thread ID) columns are added to the output.
1

Consider a process with PID p1

The task_struct object of a child process will have PPID (parent PID) as p1, and it's PID and TGID set to, say, p2.

The task_struct object of a thread of p1 will have PID set as, say p3, but TGID set to p1.

  • So you’re saying the same thing as Stephen Kitt, but much less clearly. P.S. Why bother bringing PPID into the discussion if you aren’t going to say what the PPID of a thread is? – Scott Mar 29 '18 at 2:27
  • PID and TGID are always the same. – Tim Dec 30 '18 at 23:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.