Shared Memory Synchronization 2

• The lecture begins by addressing a question: why not use actor models or software transactional memory instead of low-level synchronization?
• The answer is that operating systems live directly on top of hardware.
• Hardware fundamentally exposes shared state / shared memory.
• Therefore, kernel and OS developers must understand and handle synchronization at the low level first.
• Higher-level abstractions can be built on top of the OS, but the OS itself cannot assume them.

• Two processes (or actors) need to coordinate so that exactly one of them performs some action.
• Example: check whether there is milk; if not, go buy milk.
• This sequence is a critical section.
• The critical section is non-atomic: checking and acting are separated in time.

• Busy waiting is usually not considered a good general solution.
• The operating system provides a better abstraction: the semaphore.

• Binary semaphores and counting semaphores serve different purposes.
• Correct synchronization solutions must keep these roles conceptually separate.

• There is a bounded pool of buffers.
• Producers generate data and place it into buffers.
• Consumers take data out of buffers and return the empty buffers to the pool.

• The queue / pool state is shared.
• Access to shared queue state must be mutually exclusive.
• Producers must wait until an empty buffer exists.
• Consumers must wait until a full buffer exists.

• Wait until an empty buffer exists.
• Enter the mutex-protected critical section.
• Remove an empty buffer / update queue state.
• Leave the critical section.
• Produce / publish data.
• Signal that a full buffer is now available.

• Wait until a full buffer exists.
• Enter the mutex-protected critical section.
• Remove a full buffer / update queue state.
• Leave the critical section.
• Process the data.
• Re-enter critical-section protection if needed for shared pool bookkeeping.
• Return the empty buffer to the pool.
• Signal that an empty buffer is now available.

• Adding a second consumer requires no algorithmic change.
• Another consumer can simply run the same code.
• The semaphore-based design already supports multiple consumers correctly.

• The lecture discusses whether separate mutexes could protect different parts of the state.
• Answer: yes, that is possible.
• In real implementations, doing so may improve performance and concurrency.
• The lecture uses one mutex mainly for conceptual simplicity.

• Reordering certain V operations may be possible if the operations touch different state and are already atomic.
• However, it is often pointless.
• In general, critical sections should be kept as short as possible.

• If a consumer acquires the mutex before waiting for data, disaster may occur:
  • the consumer holds the mutex,
  • but waits for a producer to make data available,
  • while the producer cannot acquire the mutex to publish the data.
• This creates a deadlock.

• Deadlock occurs when processes are stuck waiting on one another and no progress is possible.
• Dijkstra called this a deadly embrace.

• Model processes as nodes.
• Add an edge when one process waits for a resource held by another.
• A cycle in this graph indicates deadlock.

• Once processes are in a deadlocked cycle, nothing inside the cycle can change the situation.
• Therefore, deadlock is stable unless some outside intervention occurs.

The lecture develops the standard necessary conditions.

• A lock usually protects shared state.
• If the OS simply takes the lock away, the process may already have partially modified the shared data.
• Then the protected data structure may become inconsistent or corrupted.

• In database systems, deadlock recovery is more practical because transactions keep enough information to roll back changes.
• Similar ideas inspired software transactional memory.
• But for arbitrary low-level memory manipulation in an OS kernel, rollback is difficult and expensive.

• Detect cycles in the wait-for graph.
• Then break the deadlock, for example by killing one process.

• Prevent deadlock from arising in the first place.
• Since the first three necessary conditions are hard to remove in practice, the lecture focuses on preventing circular wait.

• Impose a partial order on resources / locks.
• Processes may acquire locks only in an order consistent with that partial order.
• Then cycles become impossible.

• If every lock acquisition moves “forward” in the order, a cycle would imply:
  • \(R_1 < R_2 < \dots < R_k < R_1\),
• which is impossible.

• Not all locks in a system need to be related.
• If two locks never interact, their relative order does not matter.
• Therefore a partial order is sufficient.

• In real systems, the order may be implicit rather than globally written down.
• Every code path must respect it.
• If one path acquires \(A\) then \(B\), another path must not acquire \(B\) then \(A\).

• The lecture mentions Linux’s lockdep debugging feature.
• The kernel is too large for humans to write one global order explicitly.
• Instead, runtime checking can detect counterexamples:
  • one code path acquires locks in one order,
  • another path acquires them in the reverse order.
• Such a pair cannot both belong to the same valid partial order.

• Deadlock fundamentally arises from waiting.
• P operations may block; V operations do not block.
• Therefore ordering constraints matter primarily for blocking acquisition operations, not for releases.

• Instead of acquiring locks incrementally, require a process to request all needed resources at once.
• The request succeeds only if all are available; otherwise it gets none.

• This eliminates the hold-and-wait condition.

• In many OS scenarios, a process discovers which resource it needs next only after inspecting already locked state.
• Therefore it often cannot know all required resources in advance.

• Request every resource that might be needed.
• This is safe but pessimistic.
• It harms concurrency.

• Lock something, inspect it, unlock, then request a larger set, check again, maybe retry.
• This may work in practice, but progress can no longer be guaranteed because after releasing the lock and reacquiring a larger set of resources, the observed state may have changed, forcing the process to restart. Under contention, this restart can happen indefinitely.
• So it is not a fully satisfactory solution.

• Shared data structure, e.g. a database.
• Readers only inspect the structure.
• Writers modify it.

A reader should:

1. Wait until reading is allowed.
2. Record its presence as an active reader.
3. Perform the read.
4. Remove its presence when done.
5. Potentially wake a waiting writer when the last reader leaves.

A writer should:

1. Wait until writing is allowed.
2. Record its presence as the active writer.
3. Perform the write.
4. Remove its presence when done.
5. Wake either another writer or the waiting readers.

The lecture introduces four counters:

• AR = active readers
• AW = active writers
• WR = waiting readers
• WW = waiting writers

• One mutex to protect these counters.
• One counting semaphore okToRead.
• One counting semaphore okToWrite.

• Readers are allowed to proceed concurrently.
• Therefore the writer exit code must signal okToRead once for each waiting reader.

• The code sometimes “signals itself”:
  • when a process discovers that it may proceed immediately,
  • it records that fact by incrementing the corresponding semaphore,
  • then later consumes that permission with its own P operation.
• This keeps the structure uniform: both immediate progress and blocking cases use the same synchronization point.

• Once a writer is waiting, newly arriving readers are no longer allowed to enter immediately.
• They must wait.

• Reader-writer locks are typically used when readers are frequent and writers are less frequent but important.
• If readers were always preferred, a continuous stream of readers could starve writers forever.
• Writer preference reduces update latency.

• “Waiting” in the deadlock discussion means blocked / non-runnable waiting for an event.
• This is different from being merely preempted by the scheduler.
• A preempted process is still conceptually runnable.

• The lecture notes that checking active readers and active writers is sufficient for correctness in the given logic.
• A question revealed that one must be careful with the precise implication:
  • if a writer is waiting, then some blocking condition already existed,
  • namely active readers or an active writer.
• So the active-state checks are the essential part.

• AW is effectively binary in the presented design: either 0 or 1.
• okToRead may count multiple readers.
• okToWrite only enables one writer at a time.

• Once the OS provides semaphores, many higher-level coordination patterns can be built systematically.

• Mutual exclusion for protecting shared state.
• Condition/event synchronization for waiting on state changes.

• Incorrect acquisition order can make perfectly reasonable code deadlock.
• Preventing circular wait by lock ordering is the key practical discipline.

• Because readers may share access, but writers need exclusion.
• This creates richer state and more involved bookkeeping.