System Call - Mechanism & Modes (User vs Kernel)

▶

Steps

setup

User Process Starts Execution

The user process is created and starts executing in user mode. It is ready to run and waiting for CPU allocation.

💡 Initialization of the user process is essential to see how system calls originate from user mode.

Line:

process = create_process('UserProcess', mode='user')

💡 User processes begin in user mode and must request kernel services via system calls.

traverse

Scheduler Dispatches User Process

The scheduler selects the user process from the ready queue and dispatches it to run on the CPU in user mode.

💡 This step shows how the OS scheduler allocates CPU time to processes.

Line:

running_process = scheduler.dispatch(ready_queue)

💡 The CPU executes user code until a system call or interrupt occurs.

compare

User Process Executes System Call Instruction

The user process executes a system call instruction, triggering a software interrupt to switch to kernel mode.

💡 This step reveals how user mode code requests kernel services via a controlled interrupt.

Line:

if instruction == 'syscall': trigger_interrupt()

💡 System calls cause a controlled transition from user mode to kernel mode for safe execution of privileged operations.

expand

CPU Switches to Kernel Mode

The CPU saves user mode context and switches to kernel mode, transferring control to the kernel process to handle the system call.

💡 This step is critical to understand how the CPU changes privilege levels securely.

Line:

cpu.switch_mode('kernel'); kernel_process.state = 'running'

💡 Mode switch protects system integrity by isolating kernel execution from user code.

compare

Kernel Validates System Call Parameters

The kernel inspects and validates the parameters passed by the user process to ensure safety and correctness.

💡 Validation prevents malicious or erroneous requests from compromising the system.

Line:

if validate_params(syscall_params): proceed else: error

💡 Kernel must carefully check inputs to maintain system security.

expand

Kernel Executes Requested Service

The kernel performs the requested operation on behalf of the user process, such as reading a file or allocating memory.

💡 This step shows the kernel's privileged execution of system services.

Line:

result = kernel_service(syscall_params)

💡 Kernel executes system calls atomically and securely.

shrink

Kernel Prepares to Return to User Mode

After completing the system call, the kernel prepares to restore the user process context and switch back to user mode.

💡 Restoring context is essential to resume user process execution correctly.

Line:

restore_user_context(); cpu.switch_mode('user')

💡 Mode switch back to user mode resumes normal user process execution.

traverse

Scheduler Dispatches User Process Again

The scheduler selects the user process again to resume execution in user mode after system call completion.

💡 This step shows how the OS resumes user process after kernel handling.

Line:

running_process = scheduler.dispatch(ready_queue)

💡 User process continues execution seamlessly after system call.

insert

User Process Receives System Call Result

The user process receives the result of the system call and continues execution with the returned data.

💡 This step shows how system call results are passed back to user code.

Line:

user_process.receive_result(result)

💡 System calls provide a controlled interface for user processes to access kernel services.

traverse

User Process Continues Normal Execution

The user process continues executing in user mode after the system call, using the data returned from the kernel.

💡 This final step shows the seamless continuation of user code after kernel interaction.

Line:

user_process.continue_execution()

💡 System calls are transparent to user processes once completed.

def system_call_simulation():
    # STEP 1: Create user process
    user_process = Process(pid=1, name='UserProcess', mode='user', state='ready')
    kernel = Process(pid=0, name='Kernel', mode='kernel', state='new')

    # STEP 2: Scheduler dispatches user process
    scheduler.dispatch(user_process)

    # STEP 3: User executes syscall instruction
    if user_process.next_instruction() == 'syscall':
        # STEP 4: Switch to kernel mode
        cpu.switch_mode('kernel')
        kernel.state = 'running'
        user_process.state = 'waiting'

        # STEP 5: Kernel validates parameters
        if kernel.validate_params(user_process.syscall_params):
            # STEP 6: Kernel executes service
            result = kernel.execute_service(user_process.syscall_params)

            # STEP 7: Prepare to return to user mode
            kernel.restore_user_context(user_process)
            cpu.switch_mode('user')
            kernel.state = 'waiting'
            user_process.state = 'ready'

            # STEP 8: Scheduler dispatches user process again
            scheduler.dispatch(user_process)

            # STEP 9: User receives result
            user_process.receive_result(result)

            # STEP 10: User continues execution
            user_process.continue_execution()
        else:
            kernel.handle_error()

📊

System Call - Mechanism & Modes (User vs Kernel) - Watch the Algorithm Execute, Step by Step

Watching this step-by-step helps you understand the critical mode switches and the mechanism behind system calls, which are fundamental to OS security and functionality.

1

ready

0

new

Ready Queue

1

Waiting Queue

empty

🖥CPUidlet=0

Transition ready → running pid:1 - scheduler dispatch

1

running

0

new

Ready Queue

empty

Waiting Queue

empty

🖥CPU1t=1

1

1

running

0

ready

Ready Queue

0

Waiting Queue

empty

🖥CPU1t=2

1

Transition ready → running pid:0 - mode switch to kernel

1

waiting

0

running

Ready Queue

empty

Waiting Queue

1 (system_call_completion)

🖥CPU0t=3

1

0

1

waiting

0

running

Ready Queue

empty

Waiting Queue

1 (system_call_completion)

🖥CPU0t=4

1

0

1

waiting

0

running

Ready Queue

empty

Waiting Queue

1 (system_call_completion)

🖥CPU0t=5

1

0

Transition running → waiting pid:0 - system call complete

1

ready

0

waiting

Ready Queue

1

Waiting Queue

empty

🖥CPUidlet=6

1

0

Transition ready → running pid:1 - scheduler dispatch

1

running

0

waiting

Ready Queue

empty

Waiting Queue

empty

🖥CPU1t=7

1

0

1

1

running

0

waiting

Ready Queue

empty

Waiting Queue

empty

🖥CPU1t=8

1

0

1

1

running

0

waiting

Ready Queue

empty

Waiting Queue

empty

🖥CPU1t=9

1

0

1

Key Takeaways

✓ System calls cause a controlled switch from user mode to kernel mode to safely execute privileged operations.

This mode switch is hard to grasp from code alone because it involves CPU privilege levels and hardware interrupts.

✓ The kernel validates system call parameters to maintain system security and stability.

Seeing this validation step visually clarifies the kernel's protective role during system calls.

✓ After kernel handling, control returns to the user process transparently, allowing seamless continuation of user code.

Understanding the full cycle of request, kernel handling, and return is easier when watching the process states and mode switches.

Practice

1. Which component is primarily responsible for saving and restoring CPU registers during a context switch?

easy

A. The Interrupt Handler

B. The CPU scheduler

C. The Memory Management Unit (MMU)

D. The Process Control Block (PCB)

Solution

1. Step 1: Understand the role of PCB

   The PCB stores the CPU register states and other process information needed to resume execution later.

2. Step 2: Differentiate from scheduler and interrupt handler

   The scheduler decides which process runs next but does not save registers; the interrupt handler triggers context switches but does not save registers itself.

3. Step 3: MMU role

   The MMU handles memory address translation, unrelated to register saving.

4. Final Answer:

   Option D -> Option D

5. Quick Check:

   PCB contains saved CPU state -> correct component for saving/restoring registers.

Hint: PCB = process snapshot including CPU registers [OK]

Common Mistakes:

• Confusing scheduler with register saving
• Assuming interrupt handler saves registers
• Thinking MMU handles CPU state

2. Which of the following statements about the LRU page replacement algorithm's complexity and implementation is TRUE?

medium

A. LRU requires hardware support or additional data structures to track usage efficiently

B. LRU can be implemented with O(1) time complexity per page reference using a stack

C. LRU always performs better than FIFO regardless of workload

D. LRU does not require any extra space beyond the page frames

Solution

1. Step 1: Analyze LRU Implementation Complexity

   LRU needs to track the order of page usage, which is costly without hardware or data structures.

2. Step 2: Evaluate Each Option

   LRU requires hardware support or additional data structures to track usage efficiently is true; LRU requires hardware support or additional data structures to track usage efficiently.
   LRU can be implemented with O(1) time complexity per page reference using a stack is false; a stack alone cannot provide O(1) updates on every reference.
   LRU always performs better than FIFO regardless of workload is false; LRU can perform worse than FIFO in some workloads (e.g., scan patterns).
   LRU does not require any extra space beyond the page frames is false; LRU requires extra space for tracking usage metadata.

3. Final Answer:

   Option A -> Option A

4. Quick Check:

   Efficient LRU needs support beyond just frames.

Hint: LRU needs extra tracking structures or hardware support [OK]

Common Mistakes:

• Assuming LRU is always better than FIFO
• Believing LRU can be done with no extra space
• Thinking a simple stack suffices for O(1) LRU

3. Why is it generally inefficient to keep a process in the Ready state for a long time without scheduling it to Running, especially in a multi-core system?

medium

A. Because the process wastes CPU cache locality and increases context switch overhead when scheduled later

B. Because the process holds resources like memory and I/O devices exclusively while Ready

C. Because the process consumes CPU cycles even in Ready state, reducing overall throughput

D. Because the process cannot perform I/O operations while in Ready state, causing system deadlocks

Solution

1. Step 1: Understand Ready state resource usage

   Processes in Ready state do not consume CPU cycles but occupy scheduling queues.

2. Step 2: Analyze each option

   A: Correct. Long Ready times cause loss of CPU cache locality and increase context switch overhead when finally scheduled.
   B: Incorrect. Processes do not hold exclusive I/O or memory resources just by being Ready.
   C: Incorrect. Ready processes do not consume CPU cycles.
   D: Incorrect. Ready processes do not cause deadlocks by not performing I/O.

3. Final Answer:

   Option A -> Option A

4. Quick Check:

   Ready state delays hurt cache locality and increase context switch costs [OK]

Hint: Ready state processes wait without CPU but lose cache locality and increase context switch overhead [OK]

Common Mistakes:

• Believing Ready processes consume CPU cycles
• Assuming Ready processes hold exclusive resources
• Confusing Ready state with Waiting state regarding I/O

4. Which of the following statements about processes and threads is INCORRECT?

medium

A. Threads within the same process share the same memory space

B. Context switching between threads is more expensive than between processes

C. Processes have separate memory spaces and do not share resources by default

D. Threads can communicate more efficiently than processes due to shared memory

Solution

1. Step 1: Verify thread memory sharing

   Threads share memory within a process, so Threads within the same process share the same memory space is correct.

2. Step 2: Verify process isolation

   Processes have separate memory spaces, so Processes have separate memory spaces and do not share resources by default is correct.

3. Step 3: Compare context switching costs

   Thread context switching is lighter and faster than process switching, so Context switching between threads is more expensive than between processes is incorrect.

4. Step 4: Confirm communication efficiency

   Threads communicate efficiently via shared memory, so Threads can communicate more efficiently than processes due to shared memory is correct.

5. Final Answer:

   Option B -> Option B

6. Quick Check:

   Thread context switches are cheaper than process context switches [OK]

Hint: Thread switches cheaper than process switches [OK]

Common Mistakes:

• Assuming process context switches are cheaper
• Confusing memory sharing between threads and processes
• Believing threads cannot communicate efficiently

5. If a process requests resources that would keep the system in a safe state but the system is currently in an unsafe state, what does the Banker's Algorithm do and why?

hard

A. It denies the request because the system must always remain in a safe state, and starting from an unsafe state invalidates the algorithm's assumptions.

B. It restarts the system to reset resource allocations and ensure safety.

C. It preempts resources from other processes to restore a safe state before granting the request.

D. It grants the request because the immediate allocation is safe, ignoring the current unsafe state.

Solution

1. Step 1: Recall Banker's Algorithm assumptions

   The algorithm assumes the system starts in a safe state to guarantee deadlock avoidance.

2. Step 2: Analyze the scenario

   If the system is already unsafe, granting requests--even if individually safe--cannot guarantee overall safety.

3. Step 3: Evaluate options

   A ignores the unsafe starting state.
   B and C describe actions outside the algorithm's scope.

4. Final Answer:

   Option A -> Option A

5. Quick Check:

   Banker's Algorithm cannot recover from unsafe states; it only avoids entering them.

Hint: Banker's Algorithm requires starting safe state to function correctly [OK]

Common Mistakes:

• Assuming safe requests can fix unsafe states
• Believing the algorithm preempts resources
• Thinking system restarts are part of the algorithm