Distributed Systems in Operating Systems: Clocks, Consistency and Worked Examples

Reading a clock, calling a function and updating one value sound simple on one computer. Across several machines, those operations become uncertain because nodes communicate through messages and one node can fail while others continue. Distributed systems involve system models, communication, logical time, coordination, replication, consistency, fault tolerance and distributed file systems. Use the GATE CS Exam category to place these ideas inside your broader study route.

What makes a system distributed

A distributed system is independent nodes coordinating through messages to provide a service or manage shared resources. Its design assumes no shared memory by default, no perfect global clock, and partial failures. Process P2 may be unreachable while P1 and P3 continue.

A network operating system exposes separate machines and remote services; a distributed operating system seeks a single-system image. A distributed application can run above operating systems. Textbooks vary, so learn the architecture rather than rigid labels.

Access, location, migration, replication and failure transparency hide irrelevant distribution details, not failures that a caller must handle.

Communication, naming and the ambiguity of a timeout

Local procedure calls become message passing through send, receive, request-reply, sockets or Remote Procedure Call (RPC). Marshalling converts arguments into a transferable representation. Calls may wait synchronously or communicate asynchronously. A logical name such as inventory-service is safer than one physical address.

Suppose client C calls reserveSeat(42) with request ID r-17. The server starts with 9 seats, commits the reservation and changes the count to 8, but its reply is lost. After a 200 ms timeout, C retries. If the server treats the retry as new work, the count falls from 8 to 7. If it stores the result against r-17, it recognises the duplicate, returns the cached success and leaves the count at 8.

Retries provide at-least-once delivery attempts. Duplicate suppression can provide at-most-once execution. An end-to-end exactly-once effect also needs identifiers, durable state, atomicity and recovery rules. A timeout means the outcome is unknown, not that the first request failed.

Logical clocks and event ordering

Lamport's happened-before relation follows three rules: local program order, a message send before its matching receive, and transitivity. Each process increments its logical clock before an internal or send event. A message carries the send timestamp. On receive, the process sets L := max(local L, received L) + 1.

Start all three clocks at 0:

1. On P1, internal event a gets L=1. Send event b increments it to 2 and sends m1 with timestamp 2.

2. On P2, internal event c gets L=1. Receiving m1 at d gives max(1,2)+1=3. Sending m2 at e gives L=4.

3. On P3, receiving m2 at f gives max(0,4)+1=5. Internal event g gets L=6, and send event h gets L=7.

4. Back on P1, receiving m3 at i gives max(2,7)+1=8.

Therefore b -> d -> e -> f -> h -> i, and timestamps rise along that causal chain. Events a and c both have timestamp 1, but neither has a message path to the other, so they are concurrent in this trace. If x -> y, then L(x) < L(y). The reverse is not guaranteed: smaller timestamps alone do not prove causality. Vector clocks retain enough information to identify incomparable concurrent events. Lamport clocks provide causality-consistent ordering and, with process IDs, can support a deterministic total order.

Coordination problems need different protocols

Distributed mutual exclusion needs safety (only one process enters the critical section) and progress under stated failure assumptions. A central coordinator costs few messages but creates a failure concern. A token scheme permits only its holder to enter, but recovery must rebuild a lost token safely. A permission scheme removes the central manager but costs more messages. Clock ordering alone is not a lock.

For a leader-election trace, let IDs be {2, 5, 7, 9} before coordinator 9 crashes. Process 5 suspects failure and sends election messages to 7 and 9. Process 7 replies, starts an election toward 9, receives no reply, and becomes coordinator. It announces itself to 2 and 5. The timeout makes 9 suspected, not proven failed in a fully asynchronous network.

Election chooses a coordinator. Mutual exclusion controls critical-section entry. Consensus asks non-faulty participants to agree on one valid value and terminate under an explicit failure model. One election round does not solve general consensus.

Replication and consistency through a quorum example

Replication keeps copies to improve availability, read capacity or durability. A consistency model says which values operations may observe. A strong single-copy-style view and eventual convergence are different contracts, while session guarantees such as read-your-writes sit between them. Multiple replicas do not automatically provide strong consistency.

Take five replicas A, B, C, D, E, all initially storing x=7 at version v11. Let write quorum W=3 and read quorum R=3. A completed write stores x=9, v12 on {A,B,C}. A later read asks {C,D,E} and receives 9(v12), 7(v11), 7(v11). The read set intersects the completed write set at C, so the version rule chooses v12 and returns 9.

The checks are W+R=3+3=6 > N=5 and 2W=2(3)=6 > 5. By contrast, with W=2 and R=2, a write may finish on {A,B} while a read uses {C,D}. Then W+R=2+2=4 <= 5, so no overlap is required and the read can return stale 7(v11).

The conditions W+R>N and 2W>N guarantee read-write and write-write quorum intersections under these replica-set assumptions. Linearizability also depends on version assignment, concurrent-write resolution, failure handling and operation coordination.

Partial failures, recovery and distributed file systems

A crash stops a node, an omission loses a message or action, a timing failure violates a bound, and a Byzantine failure produces arbitrary behaviour. A heartbeat timeout creates suspicion because silence may mean node failure, link failure, delay or congestion.

Reliability is continued correct operation, availability is readiness to serve now, and durability is survival of committed data. Fault tolerance uses redundancy, durable logs, checkpoints, idempotent retries, detection, failover and recovery. Replication can improve availability but adds consistency and recovery work.

During a network partition, CAP says a system cannot guarantee both linearizable consistency and a successful response to every request. It does not require choosing two properties during normal operation.

Suppose distributed file block B7 has replication factor 3, with copies on N1, N2, N3. If N2 crashes, reads use N1 or N3, but the block is under-replicated. Recovery copies B7 from N1 to N4, restoring {N1,N3,N4}. Namespace metadata locates blocks; caching, consistency and recovery rules determine what clients observe.

Common distributed-systems traps

Typical questions ask you to compute receive timestamps, identify concurrent events, trace an RPC retry, compare coordination schemes, test W+R>N, separate consistency from availability, or explain what survives a replica failure.

Keep five corrections ready:

• A timeout does not prove the server did nothing.

• L(a)<L(b) does not prove a -> b.

• Replication alone does not provide strong consistency.

• A missed heartbeat is suspicion, not proof, in an asynchronous setting.

• CAP describes behaviour during a partition, not a permanent choice of two features.

Use Operating System MCQs for the surrounding OS foundation and Computer Networks MCQs for the communication layer beneath distributed protocols. For placement-oriented revision across OS, DBMS and networks, use CS Fundamentals for Placements by Sanchit Sir.

Distributed systems: the short version and next step

Messages replace shared assumptions. Logical clocks order causal chains. Coordination protocols solve different election, exclusion and agreement problems. Replication becomes useful only when consistency and recovery rules are explicit. Reproduce 1,2 -> 3,4 -> 5,6,7 -> 8, then explain why W=3, R=3, N=5 sees v12 while W=2, R=2 may miss it. For organised concept coverage, continue with GATE Guidance by Sanchit Sir.