GATE thread questions are usually true-or-false traps built around one confusion: what the user-space library controls and what the kernel controls. Ask who schedules the thread and what a blocking call stalls. Once those two answers are clear, most statements decide themselves.
What a thread shares and what it owns
A thread is a unit of execution inside a process. Multiple threads in one process share the process resources that define their common program environment:
code segment
global data and heap
open files and other process-level resources
Each thread must still preserve its own execution state:
program counter
CPU register set
stack
thread ID and scheduling state
This split explains both the benefit and the risk. Creating or switching a thread can be cheaper than creating or switching a complete process because the shared address space remains in place. However, two threads can access the same heap objects, so they need synchronisation when concurrent updates would race.
User-level threads: the library is in charge
Pure user-level threads are created, scheduled and switched by a library inside the process. The kernel does not see the individual threads. From the kernel's viewpoint, there is one schedulable process entity.
A user-level context switch can save one thread's registers and restore another's without trapping into the kernel. That makes the switch fast, and the library can use an application-specific scheduling policy.
The same invisibility creates two defining limits. First, if one thread performs a blocking system call, the kernel blocks the one process entity it knows. Every user-level thread mapped to that entity stops, even if another thread is ready inside the library.
Second, pure user-level threads cannot run simultaneously on several processors. The kernel has only one entity to schedule, so at most one of those threads executes at a time. The library may provide concurrency by interleaving threads, but not multicore parallelism.
Kernel-level threads: the kernel is in charge
The kernel knows every kernel-level thread and maintains its scheduling state. Each is an independent schedulable entity, even when several belong to the same process.
If one kernel thread makes a blocking call, the kernel can block that thread and schedule a sibling. If two threads are ready and two processors are available, the scheduler can run them at the same time. This is genuine parallelism.
The cost is heavier management. Creation and switching require kernel work and protected data structures. A switch selected by the kernel involves entering the kernel, running scheduler logic and restoring another thread's state. Each kernel thread also consumes kernel resources, so systems enforce resource limits rather than allowing an unlimited count.
Do not confuse a mode switch with a thread context switch. Entering the kernel changes privilege mode, but the scheduler may return to the same thread. A thread context switch changes the executing thread. The two can happen together, but they are not the same event.
The three multithreading models
The mapping between user threads and kernel threads determines which advantages survive.
Model | Mapping | Blocking call | Multicore parallelism | Main cost |
|---|---|---|---|---|
Many-to-one | Many user threads to one kernel thread | Blocks all mapped user threads | No | One kernel entity |
One-to-one | One user thread to one kernel thread | Blocks only caller | Yes | Kernel resource per thread |
Many-to-many | M user threads over N kernel threads, N <= M | Other kernel threads can continue | Yes, up to N at once | More complex coordination |
Many-to-one gives cheap user-space switching but inherits the pure user-level blocking and parallelism limitations.
One-to-one binds each user thread to a kernel thread. Linux and Windows use this general model for their native threads. It supports parallel execution and lets siblings continue when one blocks, but creating a very large number of threads consumes kernel resources.
Many-to-many multiplexes M user threads over N kernel threads, where N is no greater than M. The library schedules user threads onto available kernel threads, while the kernel schedules those entities onto processors. A blocked kernel thread need not freeze the whole application. A two-level variant also permits a particular user thread to be bound to a particular kernel thread.
Six thread-model statements decided true or false
Use two checks on every statement: what does the kernel see, and what exactly becomes blocked or scheduled?
"In a pure user-level model, if one thread makes a blocking system call, the other threads of the process keep running." FALSE. The kernel sees one process entity and blocks it. The user library cannot schedule another thread while its underlying entity is blocked.
"Kernel-level threads of one process can run on different processors at the same time." TRUE. Each is independently visible to the kernel scheduler, so two ready threads can occupy two processors.
"Switching between two pure user-level threads of the same process requires a mode switch." FALSE. The library can save and restore their user-space contexts without a trap. This is the source of the model's low switching overhead.
"Many-to-one can provide true parallelism on a multicore machine." FALSE. All user threads feed one kernel thread. The kernel can place that one entity on only one processor at a time.
"Creating a very large number of threads in one-to-one is essentially free." FALSE. Every user thread requires a kernel thread, including kernel-maintained state and scheduling resources.
"In a pure user-level model, the kernel stores every user thread's control block." FALSE. The user-space library holds those thread records. The kernel keeps state for the process entity it knows.
Statements 1, 3, 4, 5 and 6 are FALSE, while statement 2 is TRUE. Therefore the tally is five FALSE and one TRUE. Carry that count forward, not just the individual verdicts: options in a set like this often ask how many of the statements are correct rather than which one is.
How GATE tests thread models
GATE can ask which model supports parallelism, what a blocking call affects, which switch is cheaper, or how many kernel threads exist for a given mapping. It may also describe scheduler activations or the two-level model and ask you to identify cooperation between the user library and kernel. Check the current OS syllabus and weightage on the official GATE portal of the organising IIT.
The standard traps are assuming concurrency always means parallelism, assuming every thread switch changes privilege mode, and forgetting that many-to-many exists partly to avoid the many-to-one blocking problem.
Pressure-test these distinctions in Threading Models MCQs: 12 Solved Operating System Questions with Explanations, then locate them in Operating Systems for GATE: How to Study Deadlocks, Scheduling and Memory.
The short version and your next step
Pure user-level threads switch quickly, but one blocking call stalls all of them and one kernel entity prevents multicore parallelism. Kernel-level threads cost more to manage, but they block independently and can run in parallel. The mapping model decides which properties apply.
Build complete OS coverage through GATE Guidance by Sanchit Sir, use the GATE Test Series for timed statement sets, and plan the surrounding topics from the GATE CS preparation catalogue.
