In the Linux kernel, the distinction between processes and threads is minimized at the implementation level. The kernel utilizes the task_struct data structure to represent both entities, treating them as Lightweight Processes (LWPs). Despite this unification, specific mechanisms exist to manage the differences in how they share resources and relate to one another. This analysis explores the internals of task_struct, the process tree structure, and the implementation details of thread groups.

Accessing the Current Task Structure

The task_struct serves as the core descriptor for execution contexts. To efficiently access the descriptor of the currently running task on a specific CPU, the kernel relies on low-level architecture-specific mechanisms. On x86_64 architectures, information regarding the current execution context is stored at the bottom of the kernel stack within a thread_info structure.

struct thread_info {
    struct task_struct *task_ptr;  /* Pointer to the active task */
    struct exec_domain *exec_domain; /* Execution domain */
    unsigned long flags;           /* Low level flags */
    __u32 cpu;                     /* Current CPU */
    /* ... */
};

By retrieving the thread_info associated with the current stack, the kernel can obtain the pointer to the task_struct:

/* Retrieve the task_struct for the currently executing process */
struct task_struct *current_task = get_current_thread_info()->task_ptr;

The Process Hierarchy and Linked Lists

Linux organizes processes into a hierarchical tree structure. The task_struct contains specific list_head structures to maintain relationships between parents and children:

struct task_struct {
    struct list_head sibling_list;  /* List of sibling processes */
    struct list_head child_list;    /* List of child processes */
    struct task_struct *real_parent; /* The process that created this one */
    struct task_struct *parent;     /* The process receiving SIGCHLD */
    struct signal_struct *sig_struct; /* Signal handling data */
    /* ... */
};

These lists allow the kernel to traverse the process tree. The list_head nodes embedded within the task_struct act as links. Using the container_of macro, the kernel can retrieve the containing task_struct given a pointer to one of its list nodes:

/* Example: Getting the next sibling task */
struct task_struct *next_sibling = 
    container_of(current_task->sibling_list.next, 
                 struct task_struct, 
                 sibling_list);

Thread Implementation and Thread Groups

From the scheduler's perspective, a thread is simply a process that shares specific resources (address space, file descriptors, file system context, and signal handlers) with another process. The task_struct remains the unit of scheduling. However, threads are grouped logically to form what users perceive as a single "process."

When a new thread is created via the clone system call with the CLONE_THREAD flag, the kernel performs specific hendling within the copy_process function to integrate the new entity into the existing thread group:

if (clone_flags & CLONE_THREAD) {
    /* Increment the count of threads in the group */
    current->sig_struct->nr_threads++;
    
    /* Increment the live thread count */
    atomic_inc(&current->sig_struct->live);
    
    /* Increment the signal structure reference count */
    atomic_inc(&current->sig_struct->sigcnt);
    
    /* The new thread shares the group leader with the creator */
    new_task->group_leader = current->group_leader;
    
    /* Add the new task to the thread group list */
    list_add_tail_rcu(&new_task->thread_group, 
                      &new_task->group_leader->thread_group);
}

Thread Group Leadership and Management

In Linux, a "process" is essentially a thread group. The thread group is led by a "group leader" (the main thread). The task_struct includes a dedicated list head for managing threads within the group:

struct task_struct {
    struct list_head thread_group; /* List of threads in this group */
};

All child thread are linked to the leader via this thread_group list. This allows the kernel to iterate over all threads belonging to a specific process efficiently.

Resource management for the thread group is handled partly by the signal_struct. While originally intended for signals, it also tracks the lifecycle of the thread group:

struct signal_struct {
    atomic_t sigcnt;    /* Reference count for the structure */
    atomic_t live;      /* Count of live threads in the group */
    /* ... */
};

During the creation of a new process (specifically when CLONE_THREAD is not set), the copy_signal function initializes this structure:

static int copy_signal(unsigned long clone_flags, struct task_struct *dest_task)
{
    struct signal_struct *sig;

    /* Threads share the signal structure of their creator */
    if (clone_flags & CLONE_THREAD)
        return 0;

    /* Allocate new signal structure for a new process */
    sig = kmem_cache_zalloc(signal_cachep, GFP_KERNEL);
    dest_task->sig_struct = sig;
    if (!sig)
        return -ENOMEM;

    atomic_set(&sig->live, 1);
    atomic_set(&sig->sigcnt, 1);
    /* ... */
}

When creating new threads (where CLONE_THREAD is set), the kernel reuses the existing signal_struct and simply increments the live counters, as shown in the previous copy_process snippet.

Process ID (PID) vs. Thread Group ID (TGID)

The concept of a PID in user space differs slightly from the kernel implementation. In the kernel, the pid field in task_struct identifies the specific task (which acts as a Thread ID, or TID, in user space). The value that user-space tools typically report as the PID is actually the Thread Group ID (TGID).

This relationship is established during task creation:

new_task->pid = alloc_pid(vpid);       /* Unique ID for the task */
new_task->tgid = new_task->pid;        /* Default: process is its own group */

if (clone_flags & CLONE_THREAD) {
    /* Thread inherits the TGID of the creator (the process) */
    new_task->tgid = current->tgid;
}

Furthermore, the parent-child relationship changes when CLONE_THREAD is involved. A new thread's parent is not the thread that created it, but rather the parent of the entire thread group:

if (clone_flags & (CLONE_PARENT | CLONE_THREAD)) {
    /* Parent is the creator's parent (brotherly relationship) */
    new_task->real_parent = current->real_parent;
} else {
    /* Normal fork: parent is the creator */
    new_task->real_parent = current;
}

This design ensures that all threads within a group are treated as siblings with respect to the process tree, maintaining a consistent hierarchy for signal delivery and reaping.