Process vs Thread - Key Differences

▶

Steps

setup

Initialize Process A

Process A is created and added to the ready queue. It has its own memory space and resources allocated.

💡 This step sets up the first process, showing that processes are independent execution units with separate resources.

Line:

processA = create_process('A')  # STEP 1

💡 Processes are distinct entities with their own state and resources.

traverse

Schedule Process A to Run

The scheduler selects Process A from the ready queue to run on the CPU.

💡 This step shows how the CPU picks a process to execute, moving it from ready to running state.

Line:

schedule_next_process()  # STEP 2

💡 The CPU can only run one process at a time; scheduling decides which one.

insert

Process A Creates Thread T1

Process A spawns Thread T1, which shares Process A's resources but has its own execution context.

💡 This step highlights that threads belong to a process and share its memory and resources.

Line:

threadT1 = create_thread(processA, 'T1')  # STEP 3

💡 Threads are lightweight units of execution within a process.

traverse

Process A Runs and Uses CPU

Process A executes on the CPU, reducing its remaining burst time by 1 unit.

💡 This step shows how running a process consumes CPU time and progresses its execution.

Line:

execute_process(processA)  # STEP 4

💡 CPU time is consumed as processes run, moving them closer to completion.

traverse

Thread T1 Scheduled to Run

Scheduler preempts Process A and dispatches Thread T1 to run on the CPU.

💡 This step demonstrates thread scheduling within the same process context.

Line:

schedule_next_process()  # STEP 5

💡 Threads share process resources but are scheduled individually.

traverse

Thread T1 Runs and Uses CPU

Thread T1 executes on the CPU, reducing its remaining burst time by 1 unit.

💡 This step shows thread execution consuming CPU time, similar to processes.

Line:

execute_thread(threadT1)  # STEP 6

💡 Threads progress independently but share process resources.

insert

Process B Created Independently

A new Process B is created with its own resources and added to the ready queue.

💡 This step shows that processes are independent and do not share resources.

Line:

processB = create_process('B')  # STEP 7

💡 Processes have separate memory and resource spaces.

traverse

Thread T1 Completes Execution

Thread T1 finishes its CPU burst and terminates, freeing its execution context but not the process resources.

💡 This step shows thread termination without affecting the parent process's resources.

Line:

terminate_thread(threadT1)  # STEP 8

💡 Threads terminate independently but share process resources until all threads finish.

traverse

Scheduler Dispatches Process B

Scheduler selects Process B from the ready queue to run on the CPU.

💡 This step shows how the scheduler switches between independent processes.

Line:

schedule_next_process()  # STEP 9

💡 Processes are scheduled independently and have separate resource contexts.

traverse

Process B Runs and Uses CPU

Process B executes on the CPU, reducing its remaining burst time by 1 unit.

💡 This step shows process execution progressing towards completion.

Line:

execute_process(processB)  # STEP 10

💡 Each process consumes CPU time independently.

traverse

Process A Resumes Running

Scheduler switches back to Process A, which resumes execution on the CPU.

💡 This step shows context switching between processes.

Line:

schedule_next_process()  # STEP 11

💡 CPU time is shared among processes via scheduling.

delete

Process A Completes Execution

Process A finishes its CPU burst and terminates, releasing all its resources including threads.

💡 This step shows process termination and resource cleanup.

Line:

terminate_process(processA)  # STEP 12

💡 Process termination frees all associated resources and threads.

traverse

Process B Runs to Completion

Process B continues running until it finishes its CPU burst and terminates.

💡 This final step shows process execution until termination.

Line:

while processB.burst_remaining > 0:
    execute_process(processB)  # STEP 13

💡 Processes run until completion or preemption; here Process B completes uninterrupted.

def create_process(name):
    # STEP 1
    return Process(pid=name, name=f'Process {name}', state='ready', priority=1, burst_remaining=10 if name=='A' else 8)

def create_thread(process, name):
    # STEP 3
    return Thread(pid=f'{process.pid}.{name}', name=f'Thread {name} of {process.name}', state='ready', priority=1, burst_remaining=5)

def schedule_next_process():
    # STEP 2,5,9,11
    # Select next from ready_queue
    pass

def execute_process(process):
    # STEP 4,10
    process.burst_remaining -= 1

def execute_thread(thread):
    # STEP 6
    thread.burst_remaining -= 1

def terminate_thread(thread):
    # STEP 8
    thread.state = 'terminated'

def terminate_process(process):
    # STEP 12
    process.state = 'terminated'

# Main simulation loop with step comments matching visualization steps

📊

Process vs Thread - Key Differences - Watch the Algorithm Execute, Step by Step

Watching this step-by-step helps you understand the fundamental distinctions between processes and threads beyond theoretical definitions.

Transition new → ready pid:A - Process A created and ready to run

A

ready

burst: 10

Ready Queue

A

Waiting Queue

empty

🖥CPUidlet=0

Transition ready → running pid:A - Scheduler dispatched Process A to CPU

A

running

burst: 10

Ready Queue

empty

Waiting Queue

empty

🖥CPUAt=0

Transition new → ready pid:A.T1 - Thread T1 created and ready

A

running

burst: 10

A.T1

ready

burst: 5

Ready Queue

A.T1

Waiting Queue

empty

🖥CPUAt=0

Transition running → running pid:A - Process A executed 1 time unit

A

running

burst: 9

A.T1

ready

burst: 5

Ready Queue

A.T1

Waiting Queue

empty

🖥CPUAt=1

A

Transition ready → running pid:A.T1 - Thread T1 dispatched to CPU

A

ready

burst: 9

A.T1

running

burst: 5

Ready Queue

A

Waiting Queue

empty

🖥CPUA.T1t=1

A

Transition running → running pid:A.T1 - Thread T1 executed 1 time unit

A

ready

burst: 9

A.T1

running

burst: 4

Ready Queue

A

Waiting Queue

empty

🖥CPUA.T1t=2

A

A.T1

Transition new → ready pid:B - Process B created and ready

A

ready

burst: 9

A.T1

running

burst: 4

B

ready

burst: 8

Ready Queue

AB

Waiting Queue

empty

🖥CPUA.T1t=2

A

A.T1

Transition running → terminated pid:A.T1 - Thread T1 completed execution

A

ready

burst: 9

B

ready

burst: 8

Ready Queue

AB

Waiting Queue

empty

🖥CPUidlet=3

A

A.T1

Transition ready → running pid:B - Process B dispatched to CPU

A

ready

burst: 9

B

running

burst: 8

Ready Queue

A

Waiting Queue

empty

🖥CPUBt=3

A

A.T1

Transition running → running pid:B - Process B executed 1 time unit

A

ready

burst: 9

B

running

burst: 7

Ready Queue

A

Waiting Queue

empty

🖥CPUBt=4

A

A.T1

B

Transition ready → running pid:A - Process A dispatched to CPU

A

running

burst: 9

B

ready

burst: 7

Ready Queue

B

Waiting Queue

empty

🖥CPUAt=4

A

A.T1

B

Transition running → terminated pid:A - Process A completed execution and terminated

B

ready

burst: 7

Ready Queue

B

Waiting Queue

empty

🖥CPUidlet=5

A

A.T1

B

A

Transition running → terminated pid:B - Process B completed execution and terminated

Ready Queue

empty

Waiting Queue

empty

🖥CPUidlet=13

A

A.T1

B

A

B

Key Takeaways

✓ Processes have independent memory and resources, while threads share the process's resources but have separate execution contexts.

This difference is often abstract in code but becomes clear when watching resource allocation and scheduling side-by-side.

✓ Threads are scheduled independently but run within the context of their parent process, allowing lightweight concurrency.

Seeing threads enter ready and running states within the same process clarifies how they differ from full processes.

✓ CPU scheduling switches between processes and threads, demonstrating context switching and resource sharing in action.

Visualizing scheduling decisions helps understand how the OS manages multitasking and resource allocation.

Practice

1. When a timer interrupt triggers a context switch, what is the correct sequence of events that occur internally before the next process runs?

easy

A. Scheduler selects next process -> Save current CPU registers -> Load next process PCB registers -> Resume execution

B. Save current CPU registers to PCB -> Load next process PCB registers -> Scheduler selects next process -> Resume execution

C. Save current CPU registers to PCB -> Scheduler selects next process -> Load next process PCB registers -> Resume execution

D. Load next process PCB registers -> Save current CPU registers -> Scheduler selects next process -> Resume execution

Solution

1. Step 1: Save current process state

   Before switching, CPU registers of the current process must be saved to its PCB.

2. Step 2: Scheduler decision

   After saving, the scheduler selects the next process to run.

3. Step 3: Load next process state

   The CPU registers of the selected process are loaded from its PCB.

4. Step 4: Resume execution

   The CPU resumes execution with the new process context.

5. Final Answer:

   Option C -> Option C

6. Quick Check:

   Saving registers before scheduler decision and loading registers after is the correct order.

Hint: Save first, then schedule, then load -> context switch order [OK]

Common Mistakes:

• Selecting next process before saving current registers
• Loading next process registers before scheduler decision
• Mixing order of save/load and scheduling

2. In which scenario is preemptive Shortest Job First (SJF) scheduling preferred over non-preemptive SJF?

easy

A. When new processes with shorter burst times can arrive at any time during execution

B. When fairness is not a concern and starvation is acceptable

C. When minimizing context switch overhead is the highest priority

D. When all processes arrive at the same time and have similar burst times

Solution

1. Step 1: Understand preemptive SJF behavior

   Preemptive SJF allows the CPU to switch to a newly arrived process if it has a shorter burst time than the currently running process.

2. Step 2: Analyze scenarios

   If new processes with shorter burst times can arrive anytime, preemptive SJF ensures the CPU always runs the shortest job next, improving average waiting time.

3. Step 3: Why other options are incorrect

   A: If all processes arrive simultaneously with similar burst times, preemptive advantage is minimal.
   B: Starvation is a concern in preemptive SJF, so it's not chosen when fairness is ignored.
   C: Preemptive SJF increases context switches, so it's not preferred when minimizing overhead.

4. Final Answer:

   Option A -> Option A

5. Quick Check:

   Preemptive SJF is best when shorter jobs can arrive anytime, requiring immediate preemption.

Hint: Preemptive SJF shines when shorter jobs arrive unpredictably [OK]

Common Mistakes:

• Assuming preemptive SJF always reduces overhead
• Believing preemptive SJF is best when all jobs arrive simultaneously

3. Which of the following statements about Peterson's algorithm is INCORRECT?

medium

A. It can be extended straightforwardly to more than two processes

B. It guarantees mutual exclusion between two processes

C. It ensures progress and bounded waiting

D. It does not require special hardware instructions

Solution

1. Step 1: Verify correctness of each statement

   Options A, C, and D are true properties of Peterson's algorithm.

2. Step 2: Identify incorrect statement

   It can be extended straightforwardly to more than two processes is incorrect because Peterson's algorithm is specifically designed for two processes and does not extend easily to multiple processes.

3. Final Answer:

   Option A -> Option A

4. Quick Check:

   Peterson's algorithm is a two-process solution only.

Hint: Peterson's = two-process only, no hardware needed, guarantees progress

Common Mistakes:

• Assuming easy extension to multiple processes
• Confusing bounded waiting with starvation
• Believing hardware instructions are required

4. Which of the following statements about Effective Access Time (EAT) in systems using TLB is INCORRECT?

medium

A. A TLB miss always causes a page fault, increasing EAT drastically

B. EAT depends on both TLB hit ratio and memory access time

C. EAT can be calculated as (TLB hit ratio x TLB access time) + (TLB miss ratio x page table access time)

D. Improving TLB hit ratio reduces the average memory access time

Solution

1. Step 1: Recall EAT formula

   EAT = (hit ratio x access time on hit) + (miss ratio x access time on miss)

2. Step 2: Analyze each statement

   A: Correct, EAT depends on hit ratio and memory times.
   B: Incorrect, TLB miss does not always cause page fault; it triggers page table lookup.
   C: Correct, formula reflects hit and miss costs.
   D: Correct, higher hit ratio lowers average access time.

3. Final Answer:

   Option A -> Option A

4. Quick Check:

   TLB miss ≠ page fault; page fault only if page not in memory.

Hint: TLB miss ≠ page fault; page fault only if page absent [OK]

Common Mistakes:

• Confusing TLB miss with page fault
• Misapplying EAT formula

5. If Peterson's algorithm is used on a modern multi-core processor with weak memory ordering (e.g., relaxed memory consistency), what is a likely issue that can arise, and how can it be addressed?

hard

A. The algorithm will cause starvation because weak memory ordering breaks bounded waiting

B. The algorithm will cause deadlock because weak memory ordering delays flag updates

C. The algorithm will work correctly without modification because it uses only atomic variables

D. The algorithm may fail mutual exclusion due to instruction reordering; inserting memory barriers can fix this

Solution

1. Step 1: Understand weak memory ordering impact

   Modern processors may reorder instructions, causing visibility issues for shared variables.

2. Step 2: Effect on Peterson's algorithm

   Without memory barriers, the flags and turn variables may be seen out of order, breaking mutual exclusion.

3. Step 3: Solution

   Inserting memory fences/barriers enforces ordering and visibility, preserving correctness.

4. Final Answer:

   Option D -> Option D

5. Quick Check:

   Memory barriers are essential on weakly ordered architectures for software synchronization.

Hint: Weak memory ordering -> need memory barriers for Peterson's correctness

Common Mistakes:

• Assuming Peterson's works without modification on all hardware
• Confusing deadlock with visibility delays
• Believing atomic variables alone guarantee correctness