Threads Practice Questions

Let's analyze each statement about threads:
(a) Threads can only be implemented in Kernel space: This is FALSE. Threads can be implemented in kernel space (kernel-level threads) or user space (user-level threads), or a hybrid approach.
(b) Each thread has its own file descriptor table for open files: This is FALSE. Threads within the same process share the same file descriptor table, meaning they share open files. Each process has its own file descriptor table, but threads within that process share it.
(c) All the threads belonging to a process share a common stack: This is FALSE. Each thread has its own private stack to store local variables and function call information. While threads share code, data, and open files, their stacks are separate.
(d) Threads belonging to a process are by default not protected from each other: This is TRUE. Threads within the same process share the same address space, including global variables and heap. This shared access means they can directly access and modify each other's data, leading to potential race conditions and requiring explicit synchronization mechanisms (like mutexes or semaphores) for protection.

Therefore, statement (d) is TRUE.

When switching context between threads of the same process, certain resources are shared, while others are thread-specific.
The page table base register typically points to the page table of the process, which is shared among threads of the same process. So, it does not need to be saved.
However, each thread has its own stack, program counter, and general-purpose registers.
Therefore, the stack pointer, program counter, and general-purpose registers must be saved and restored during a context switch between threads.
The correct options are B, C, and D.

The variable x is global and shared between processes. Each process (P1 and P2) spawns two threads (T1 and T2). Each thread executes foo(). Inside foo(), x is incremented within a critical section protected by Lock L1. Since x is global, all four threads (P1-T1, P1-T2, P2-T1, P2-T2) will increment the same x. If all four threads execute, x will be incremented four times, resulting in x=4.
The variable y is local to foo(), meaning each call to foo() (by each thread) gets its own y. So, each thread will initialize y=0, increment it to y=1, and print y=1.
Therefore, both P1 and P2 will print x=4 (after all threads finish), and all threads will print y=1.
Options A and D are correct.

Threads within the same process share certain resources while maintaining their own execution context. The shared resources include the address space (which contains the code, data, and heap sections). However, each thread has its own program counter, stack, and set of registers to manage its independent execution flow. Therefore, only the address space is shared among all threads of a process.

Threads within the same process operate in a shared memory space. This shared space includes the code segment, data segment (for global variables), and the heap (for dynamically allocated memory). Each thread, however, has its own separate stack for local variables and function calls, as well as its own set of registers, including the program counter. Therefore, threads of a process share both global variables and the heap.

User-level threads are managed by user-space libraries, meaning the kernel does not schedule them, making statement A true. In user-level threading, the kernel recognizes only the process; thus, a blocking system call halts the entire process, confirming statement B. Context switching between user-level threads avoids costly transitions to kernel mode, making statement C true. Conversely, all threads within the same process, including kernel-level threads, share the same virtual address space, which encompasses the code segment, data segment, and heap. Therefore, the assertion that kernel-level threads cannot share the code segment is false.

Switching between user and kernel modes ($t_1$) involves a change in privilege level within the same process. This is a relatively lightweight operation.
Switching between two processes ($t_2$), also known as a context switch, requires saving the state of the current process and loading the state of another process. This includes switching address spaces, CPU registers, and often flushing caches, which is a more computationally intensive operation.
Since a process switch ($t_2$) necessarily involves a mode switch (at least from user to kernel to perform the switch, and then kernel to user for the new process), plus additional overhead for changing process context, it will always take longer than a simple mode switch ($t_1$).
Therefore, $t_1$ is less than $t_2$.

A thread is considered a 'lightweight process' because it shares many resources with other threads within the same process.
The operating system does not maintain separate virtual memory state (like page tables) for each thread, as threads within the same process share the same virtual address space.
However, each thread does require its own CPU register state, its own program counter, and its own stack for function calls and local variables. Scheduling and accounting information is typically managed at the process level or for the thread itself, but not exclusively for the process.

A. Context switching for kernel-level threads requires switching between kernel states, which is generally slower than switching between user-level threads, which occurs entirely in user space. So, A is true.
B. User-level threads are implemented by a user-level library without kernel intervention, thus requiring no special hardware support beyond the standard CPU. So, B is true.
C. Kernel-level threads are distinct schedulable entities managed by the OS. In a multi-processor system, the OS scheduler can assign different kernel-level threads to different processors. So, C is true.
D. If one kernel-level thread blocks (e.g., for I/O), other kernel-level threads within the same process can continue to execute, as each is independently managed by the kernel. This statement describes the behavior of user-level threads in a many-to-one mapping, not kernel-level threads. Thus, D is false.

The false statement is D.

(i) is False because context switching between user-level threads ($T_{user}$) occurs in user mode, making it faster than switching between kernel-supported threads ($T_{kernel}$) which requires costly mode transitions.
(ii) is True because the kernel is unaware of internal $T_{user}$ management; thus, a blocking system call from one $T_{user}$ suspends the entire process.
(iii) is True because $T_{kernel}$ are distinct scheduling entities managed directly by the operating system scheduler.
(iv) is True as $T_{user}$ are handled by a user-space runtime library, keeping them transparent to the kernel.
Thus, statements (ii), (iii), and (iv) are correct.

Threads belonging to the same process share common resources, including the process's $Address \ Space$, global data, heap, and the file descriptor table. However, to execute functions independently, every thread requires its own unique execution context. This context includes a private $Stack$ to store local variables, function parameters, and return addresses, and a private register set (including the program counter). Therefore, while the address space and file descriptors are shared, the $Stack$ is unique to each thread.