E ExamMaster

GATE Computer Science & IT · Operating Systems

Threads

Threads share a process's address space; user-level versus kernel-level scheduling.

maya is still PID 1420. This lesson splits her into a UI thread and a save thread: same heap, same open files, two stacks. Then it asks who schedules those threads — a user-space library (fast, one block stalls all) or the kernel (true parallelism).

  • GATE Computer Science & IT
  • Medium level
  • 3 concepts

1A thread is not a second process

A second process would be a new PID with its own address space. A second thread of maya is still PID 1420. kill(1420) hits every thread. An open file table is shared: if the save thread closes essay.txt, the UI thread sees it closed.

Use a process when you want isolation — Spell should not be able to scribble on maya's heap. Use a thread when you want cheap concurrency inside one program — UI and save taking turns on one PID.

Figure. One process, two stacks. The heap and PID are shared; each thread has its own PC.

What is shared

  1. SharedCode, global data, heap, open files, PID 1420.
  2. PrivateEach thread's stack, registers, and program counter.
  3. Not a PIDThreads are not processes. The kernel may still schedule them, but the PID is the process's.
Process versus thread
ThingNew processNew thread of maya
PIDNew numberStill 1420
Address spaceCloned or newShared
Stack / PCIts ownIts own
Open filesUsually copiedShared table
Which resource do threads of maya NOT share?
  1. Their stacks and program counters
  2. The process's open file table
  3. The process's global data

Stacks and PCs are per thread. Files and globals belong to PID 1420.

2Threads share the process

maya is still one process, PID 1420. A thread is a separate program counter, register set and stack inside that process. Maya's editor can keep a UI thread drawing the window and a save thread writing essay.txt. Both threads share 1420's code, global data and open files. They do not each get a copy of the address space.

That is why creating a thread is cheaper than creating a process: the kernel does not clone page tables. It is also why races are easy. If both threads write the same global — say unsaved_count — they need a lock. The next lesson is that lock.

Figure. The upper half is process-wide. The lower half is one private column per thread. Concurrency is cheap because only the lower half is duplicated.

What is shared

  1. SharedCode segment, heap/globals and open file table belong to the process.
  2. PrivateEach thread owns a stack, a register set and a PC.
  3. ConsequenceLow creation cost and true shared-memory communication — at the price of races on the shared half.

Memory footprint of four threads

maya's process (PID 1420) has one 2 MB heap shared by all its threads. She spawns 4 threads, each with its own 512 KB stack. Ignoring code, how much memory does the process use for heap plus stacks?

  • shared heap, one copy for the whole process2 MB = 2048 KB
  • per-thread stacks = 4 x 512 KB2048 KB
  • heap + stacks = 2048 + 2048 KB4096 KB = 4 MB

Pro tip. The heap is counted once because threads share it; only the stack multiplies per thread. That is why a thread is cheaper than a whole second process, which would copy the heap too.

Two threads of the same process each call a function. Which resource is private to each thread?
  1. The process's open file table
  2. The call stack used by that function
  3. The program's global variables

Each thread has its own stack (and registers/PC). The open-file table and globals are process-wide and therefore shared.

3User-level versus kernel-level threads

Who schedules the UI thread and the save thread? Two answers, and they are not the same speed.

User-level threads are switched by a library inside PID 1420. The kernel sees one schedulable entity — the process. A switch is a function call, so it is fast. The cost: if the save thread issues a blocking disk read, the kernel blocks the whole process. The UI thread freezes too, because the kernel does not know it exists.

Kernel-level threads are known to the OS scheduler. Each thread is a schedulable entity. The save thread can block on disk while the UI thread keeps Running. That is true parallelism on a multi-core machine, and a slightly more expensive switch, because it is a real context switch.

Figure. Kernel-visible threads can overlap I/O; pure user threads share one kernel schedulable entity.

How each kind is scheduled

  1. User-levelThe library maps many user threads onto one (or a few) kernel entities; the kernel is unaware of the rest.
  2. Kernel-levelEach thread is a kernel scheduling unit, so blocking and multiprocessor dispatch are per-thread.
  3. Trade-offUser-level wins on switch cost; kernel-level wins on blocking behaviour and parallelism.
User-level vs kernel-level
PropertyUser-levelKernel-level
Who schedulesUser libraryOS kernel
Switch costLow (no kernel trap)Higher (kernel involved)
One blocking callCan block all threads of the processBlocks only that thread
True parallelismNo (one kernel entity)Yes, across cores

How many threads run at once

A pure user-level library maps 8 of maya's user threads onto 1 kernel-scheduled entity, running on a 4-core CPU. At most how many of maya's threads execute in true parallel at one instant?

  • cores available4
  • kernel-scheduled entities the library exposes1 (the kernel sees one process)
  • true parallelism = min(kernel entities, cores) = min(1, 4)1 thread at a time

Pro tip. Pure user-level threads share one kernel entity, so extra cores cannot help; parallelism is capped by the number of kernel-scheduled units, not by the core count.

A process uses purely user-level threads. One thread blocks in a read() system call. What happens to the others?
  1. They keep running on other cores
  2. They are also stalled, because the kernel scheduled the whole process
  3. The library preempts the blocked thread automatically inside the kernel

The kernel sees one process. When that process blocks in the kernel, every user-level thread sharing it stalls until the blocking call returns.

Notes

  • Threads of one process share code, data and open files; each has its own stack, registers and PC.
  • User-level threads are fast to switch and invisible to the kernel; one blocking call blocks all.
  • Kernel-level threads are scheduled by the OS and can run in parallel on several cores.

Formulas

  • A thread context switch is cheaper than a process switch when the address space (and TLB) need not change.

Exam traps & shortcuts

  • If the question says 'one blocking call blocks all threads', the package is user-level.
  • Shared heap is the race: two threads, one global, need a lock.

Reference tables

Save thread reads the disk. What happens to the UI thread?

Who sees a blocking read
Thread packageKernel seesUI thread during a blocking read
User-levelOne process, PID 1420Stalls — the process is blocked
Kernel-levelTwo schedulable threadsCan keep Running

Recap

A thread is a stack inside a PID. User-level packages hide extra threads from the kernel.

Share
Code, heap, files, PID. Private: stack, regs, PC.
Not a process
No new PID. Isolation wants a process; cheap concurrency wants a thread.
User-level
Fast switch. One blocking syscall stalls every thread in the process.
Kernel-level
OS schedules each thread. One can block while another runs.

Practise Threads

Reading is free and needs no account. Practice, mocks and progress live in the app.

  • A 2-question practice set that ends the chapter
  • 3 quick checks with worked explanations
  • Timed mocks scored with the real marking scheme
  • Readiness tracked per topic, kept on your device
Continue with Google — freeNo card, no trial. Works offline once installed.