Operating System

Answer: (i) Naming (Direct Naming / Direct Communication)

In IPC, direct communication requires sender/receiver to explicitly name each other (send(P,message), receive(Q,message)). This is called naming / direct addressing. Indirect uses mailboxes/ports. Message Passing is the overall category, Naming is the specific mechanism for direct.

Answer: (iv) Virtual memory

Mutual exclusion solutions: busy-wait (Peterson, strict alternation), hardware (TSL, swap), semaphores, monitors, message passing, event counters. Virtual memory is memory management, not synchronization.

Answer: (iii) Process synchronization and deadlock

Dining philosophers share forks (resources); illustrates synchronization, deadlock, starvation. Classic IPC problem solved by semaphores/monitors.

Answer: (iv) One

Critical section property: at most one process may execute inside CS at any time to ensure mutual exclusion and avoid race condition.

Answer: (iii) Race condition between processes

Critical section is code segment accessing shared data. Mutual exclusion ensures only one process executes CS at a time to prevent race where outcome depends on timing.

Answer: (ii) Only one process enters the critical section at a time

Peterson's flags+turn ensures mutual exclusion, progress, bounded waiting for 2 processes without hardware support.

Race Condition

Occurs when multiple processes/threads access shared data concurrently and outcome depends on order of execution.
Example: shared counter x=5, P1: x=x+1, P2: x=x-1 interleaved without sync can give wrong result. Other examples: lost update in database, inconsistent file write, printer spooler with two producers updating buffer indices.
Requires mutual exclusion, atomic operations.

Critical Section Problem

Code segment where shared resources accessed. Requirements: 1) Mutual Exclusion (only one in CS), 2) Progress (decision in finite time if no one in CS), 3) Bounded Waiting (limit on waiting). Solutions: software (Peterson), hardware (TSL, swap), semaphores, monitors.

(a) Semaphore & Primitives

Integer variable with atomic wait(S)/signal(V). Binary (0/1) vs counting. wait: while s≤0 wait, s-- ; signal: s++ and wake. Implementation via blocking queue, disable interrupts for atomicity.

(b) Critical Section

Segment accessing shared data. Requirements as before; solutions: mutex, semaphore (wait before CS, signal after), monitors.

Semaphore

Integer sync variable. Dining Philosophers with Monitor: monitor with 5 condition vars, state[] = thinking/hungry/eating, test(i) checks neighbors not eating, pickup puts hungry then test, putdown sets thinking then tests neighbors. Monitor ensures mutex, prevents deadlock/starvation vs semaphore solution with deadlock risk.

Producer-Consumer with Semaphore

Shared buffer size N, sem empty=N, full=0, mutex=1.
Producer: wait(empty), wait(mutex), produce to buffer, signal(mutex), signal(full)
Consumer: wait(full), wait(mutex), consume, signal(mutex), signal(empty)
Guarantees mutual exclusion via mutex, and counting sems prevent overflow/underflow, bounded waiting.

Producer-Consumer

As Q23: bounded buffer problem, solution with semaphores empty/full/mutex as above.

Critical Section & Peterson

Critical section needs mutual exclusion, progress, bounded waiting. Peterson for 2 processes: shared flag[2], turn. Pi: flag[i]=true; turn=j; while(flag[j] && turn==j) wait; CS; flag[i]=false; remainder. Proves mutual exclusion.

Readers-Writers with Semaphores

shared int readcount=0; sem mutex=1, wrt=1;
Reader: wait(mutex); readcount++; if(readcount==1) wait(wrt); signal(mutex); read; wait(mutex); readcount--; if(readcount==0) signal(wrt); signal(mutex);
Writer: wait(wrt); write; signal(wrt);
Readers preference variant, writer may starve; for writer preference add extra sem.

Peterson's Solution

Software mutual exclusion for 2 processes using flag[] and turn, guarantees mutex, progress, bounded waiting without hardware.