Learn · CS Fundamentals
OS Fundamentals
The handful of operating-system ideas that show up in interviews and in every real backend: processes, threads, memory, and deadlocks.
Before we start
- Process vs thread — the difference that matters
- Why threads are powerful and dangerous (shared memory)
- Stack vs heap memory, and 32 vs 64-bit
- What a deadlock is and how to avoid it
- Explain process vs thread with an example
- Describe a race condition and why locks fix it
- Say what a deadlock is and one way to prevent it
Why you’re learning it: Siemens’ MCQs cover OS basics, and the concurrency ideas here explain the bugs behind real production incidents. ⏱️ ~30 min.
Process vs Thread
A process is a running program with its own private memory. A thread is a lighter worker inside a process that shares that memory with its siblings. Picture a house (process) with several people (threads) living in it — they share the kitchen and fridge (memory).
Isolated own memory. Crashing one doesn’t crash others. Heavier to start.
Shares the process’s memory — great for doing many things at once (handling requests), but shared memory is where bugs hide.
The danger — race conditions
Two threads share the fridge. Both check “milk? no”, both go buy milk — now there are two. In code, two threads read a balance at the same time and both write a stale value (the money race from Transactions). The fix is a lock: only one thread touches the shared thing at a time. Too many locks in the wrong order, though, and you get…
Deadlock
Two friends at dinner, one chopstick each, both waiting for the other’s to start eating. Neither moves — forever. In code: thread A holds lock 1 and wants lock 2; thread B holds lock 2 and wants lock 1. Frozen. Prevention: always acquire locks in the same order everywhere, so the circular wait can’t form.
Memory — stack vs heap
| Stack | Heap | |
|---|---|---|
| Holds | Function calls, local variables | Objects, anything long-lived / dynamic |
| Speed | Very fast, auto-cleaned | Slower, managed (garbage collected in Java) |
| Runs out? | Deep recursion → stack overflow | Too many objects → out of memory |
32 vs 64-bit mostly means how much memory a program can address: 32-bit tops out around 4 GB; 64-bit is effectively unlimited — which is why everything is 64-bit now.
Where you’ll use it — real life
Handling thousands of requests at once is threads (or async) — and race conditions are the classic production bug.
Concurrent invocations touching shared data hit exactly these issues.
A service that hangs under load is often a deadlock — now you know what to look for.
“StackOverflowError” and “OutOfMemoryError” make sense once you know stack vs heap.
Now YOU do the reps
These are understanding topics — practise by explaining, not by LeetCode:
- Describe a race condition in your own words, and how a lock fixes it.
- Draw the two-thread deadlock and explain the lock-ordering fix.
- Say which lives on the stack and which on the heap for a small program.
Out loud: “What’s the difference between a process and a thread, and what is a deadlock?” Then log it in your Journal.
Back to your Siemens roadmap →