ایک context switch اصل میں کیا لاگت رکھتا ہے، اور یہ کیوں اہمیت رکھتا ہے؟

Question

IT Interview Practice · Accepted Answer

ایک **context switch** یہ ہے کہ kernel اس وقت چل رہے thread کی CPU حالت (registers، program counter، stack pointer) کو محفوظ کرتا ہے اور کسی دوسرے thread کی بحال کرتا ہے، تاکہ ایک ہی core بہت سے threads کو multiplex کر سکے۔ یہ ہر scheduler preemption، blocking syscall، یا interrupt پر ہوتا ہے — اور یہ مفت نہیں ہے۔

## لاگت کہاں چھپی ہوتی ہے

```text
DIRECT cost (visible, ~1–5 µs):
  save/restore registers · run scheduler logic · switch kernel stacks
  if PROCESS switch: also swap page tables (CR3) → FLUSHES the TLB

INDIRECT cost (often much larger):
  cold CPU CACHES → the new thread's data isn't in L1/L2/L3 → cache misses to RAM
  cold TLB        → address translations must be re-walked
  lost pipeline / branch-predictor state
```

**براہِ راست** لاگت چند microseconds ہے۔ **بالواسطہ** لاگت — switch کے بعد ٹھنڈا cache اور TLB — اکثر بڑی چوٹ ہوتی ہے: آنے والا thread کچھ دیر سست چلتا ہے جب وہ مرکزی میموری سے اپنے caches دوبارہ گرم کرتا ہے (فی miss دسیوں سے سینکڑوں cycles)۔

## thread بمقابلہ process switch

ایک ہی process کے **threads کے درمیان** switching سستی ہے: وہ ایک address space شیئر کرتے ہیں، اس لیے page table (اور TLB، بغیر tagged TLBs / PCIDs والے ہارڈویئر پر) کو بدلنے کی ضرورت نہیں۔ **processes** کو switch کرنا اضافی طور پر page-table base register دوبارہ لوڈ کرتا ہے اور روایتی طور پر TLB کو flush کرتا ہے — یہی وجہ ہے کہ اس کی لاگت زیادہ ہے۔

## یہ عملی طور پر کیوں اہم ہے

- **بہت زیادہ threads** → scheduler thrash کرتا ہے، کام کرنے کے بجائے switch کرنے میں cycles خرچ کرتا ہے؛ ایک حد کے بعد، cores سے زیادہ threads throughput کو *کم* کر دیتے ہیں۔
- یہ **async / event-loop** ماڈلز (Node، nginx، `io_uring`) اور **goroutines / green threads** کے لیے بنیادی دلیل ہے: کم OS threads کے ساتھ بہت سے connections سنبھالیں، فی request ایک switch سے بچتے ہوئے۔
- یہی وجہ ہے کہ **CPU pinning / affinity** latency کے حساس services کی مدد کرتی ہے — ایک thread کو ایک core پر رکھیں تاکہ اس کا گرم cache محفوظ رہے۔
- involuntary context-switch کی زیادہ گنتی (`vmstat`، `pidstat` میں نظر آتی ہے) lock contention یا CPU oversubscription کی ایک کلاسک علامت ہے۔

## یہ کیوں اہم ہے

یہ ایک senior-level سوال ہے کیونکہ یہ ان لوگوں کو جو *اصطلاح* جانتے ہیں ان سے الگ کرتا ہے جو سمجھتے ہیں کہ یہ *کیوں* مہنگا ہے — اور حقیقی جواب (cache/TLB آلودگی، صرف register محفوظ کرنا نہیں) تعمیراتی فیصلوں کو چلاتا ہے: thread-per-request کے بجائے async I/O، thread pools کو core count کے مطابق صحیح سائز دینا، اور affinity استعمال کرنا۔ یہ scheduling، virtual memory، اور CPU caches کو ایک ہی پرفارمنس کہانی میں باندھ دیتا ہے۔

لاگت کہاں چھپی ہوتی ہے

thread بمقابلہ process switch

یہ عملی طور پر کیوں اہم ہے

یہ کیوں اہم ہے

متعلقہ سوالات