Shared Memory Synchronization 1

• The lecture begins by revisiting the two basic approaches to communication and coordination between processes:
  • message passing
  • shared memory

• The lecture distinguishes:
  • true message passing as an OS primitive, versus
  • manually building something that behaves like message passing on top of shared memory.
• One can emulate a mailbox using shared memory, but then one no longer automatically gets the semantic guarantees and convenient abstraction of the OS primitive.

The main reason to use shared memory is performance. Since communication becomes ordinary loads and stores, it can support much higher communication rates and larger data transfers than explicit message passing.

The lecture gives an example such as a video-processing pipeline: moving large frames at high frequency between stages may be impractical with message passing, but feasible with shared memory.

The drawback is that shared memory reintroduces all the difficulties of concurrent access to shared state:

• ordering becomes crucial,
• correctness depends on the interleaving of operations,
• bugs can be timing-dependent and difficult to reproduce.

The lecture notes that such systems are often called “non-deterministic,” though more precisely the execution is deterministic given a fixed thread schedule; the problem is that the schedule is typically unknown or hard to reproduce. This leads to classic heisenbugs: errors that appear in one run and disappear in the next.

To make the issue concrete, the lecturer considers two processes writing:

• one writes ABC,
• the other writes CBA.

Because execution can interleave arbitrarily, many mixed outputs are possible. For example, something like CBC can occur under a suitable interleaving.

However, not every string is possible. Each individual process still executes its own instructions in order, so no output may violate the per-process ordering constraints. The lecture ends by using this example to motivate synchronization primitives, which will be continued in the next lecture.

• Once state is shared, the order of accesses becomes significant.
• The behavior of the system may then depend on:
  • the interleaving chosen by the scheduler,
  • the relative speed of the processes or threads,
  • the exact hardware guarantees.

• Not all operations are sensitive to order.

• Example:

  A = 1   ||   B = 2
  

• These operations affect different variables, so the final state is independent of order.

• Example:

  A = B + 1   ||   B = 2 * B
  

• Here, the result depends on which operation happens first.
• If the assignment to A happens first, A gets the old value of B + 1.
• If the doubling of B happens first, then A may see the doubled value of B and compute a different result.

• Example:

  A = 1   ||   A = 2
  

• Without further assumptions, the outcome is hardware-dependent.
• One might see:
  • 1,
  • 2,
  • or potentially even a corrupted/interleaved result, if the hardware does not guarantee atomicity for that write.

• The outcome of concurrent shared-memory execution cannot be reasoned about purely at source-code level.
• It depends crucially on what the hardware guarantees.

• An atomic operation is an operation that cannot be interrupted “in the middle”.
• It either happens entirely or not at all, from the perspective of concurrent observers.

• Suppose the hardware guarantees that writes to aligned 16-bit words are atomic.

• Then, if A is a 16-bit aligned variable:

  A = 1   ||   A = 2
  

  cannot produce some mixed intermediate bit pattern such as 3.

• In that case, the final outcome must be either 1 or 2.

• The lecture emphasizes the distinction between:
  • aligned accesses: address is a multiple of the word size,
  • non-aligned accesses: address is not a multiple of the word size.
• Typical hardware often guarantees atomicity only for certain native aligned word accesses.
• Non-aligned accesses are often not atomic.

• Even if 16-bit aligned writes are atomic, a 32-bit value spanning two 16-bit words is not automatically atomic.

• Example:

  A = 0x1   ||   A = 0x10000
  

• If the two writes update different halves of the 32-bit value independently, one can observe a mixed result.

• The lecture gives the example that such an execution can yield a hybrid value such as:

  0x100001
  

• The key point is:
  • word-level atomicity does not imply atomicity for larger multi-word objects.

• Atomicity properties are not universal.
• One must understand the guarantees of the actual hardware/platform.
• Common hardware-level atomic primitives include:
  • word-aligned load/store,
  • fetch-and-increment,
  • test-and-set,
  • compare-and-exchange / compare-and-swap (CAS).

• Never assume an access is atomic unless the hardware/platform specification says so.
• Concurrency reasoning must be grounded in the exact machine model.

• A race condition occurs when processes or threads are “racing” to perform conflicting operations.
• The outcome then depends on:
  • interleaving,
  • relative timing,
  • process speed.

• Usually, race conditions are considered bugs.
• They make behavior:
  • nondeterministic,
  • hard to reproduce,
  • hard to debug.

• The lecture briefly notes that some races can be benign in practice.
• However, this is an exception.
• In general, races should be treated as incorrect unless there is a very strong reason not to.

• The goal of synchronization is to eliminate unwanted timing dependence and make the system behavior deterministic with respect to the intended specification.

• The lecture introduces a deliberately simple but instructive example:
  • two roommates / robots,
  • one fridge,
  • milk should be bought if there is none,
  • but there should not be too much milk,
  • ideally exactly one bottle is bought when needed.

• If both agents independently observe “no milk” and both decide to go shopping, then both may buy milk.
• The outcome depends on timing.
• This is precisely a race condition.

• The example is simple, but it captures the core of synchronization:
  • conflicting operations on shared state,
  • need for mutual exclusion,
  • need for progress,
  • need to separate specification from implementation.

• Before trying to “fix” concurrency bugs, one must first specify what correct behavior actually means.
• The lecture explicitly warns against prematurely diving into low-level implementation details.

• A correct solution should satisfy at least the following:

• The relevant instructions that manipulate the shared decision state form a critical section.
• A key synchronization goal is:
  • critical sections that conflict must not execute simultaneously.

• A first idea is to use a note on the fridge:
  • if there is no milk, leave a note saying “I’m taking care of it”,
  • then go buy milk.

• The problem is that:

  • checking the fridge,
  • and leaving the note,

  are not atomic together.

• Both agents may:
  1. observe that there is no milk,
  2. observe that there is no note,
  3. both leave a note,
  4. both go buy milk.
• This only makes the bug less likely, not impossible.

• Making a race harder to trigger does not make the program correct.
• The lecture explicitly points out this common anti-pattern:
  • “it doesn’t fail anymore” does not imply correctness.

• The lecture then considers a more complicated protocol where the two processes execute different code.
• This can be made to avoid double-buying in some cases.

• They are awkward from a software engineering perspective.
• Different threads/processes now need different code.
• Extending the scheme to a third participant becomes unpleasant.
• Such solutions may also introduce unfairness or bias.

• Busy waiting (or spinning) means repeatedly checking a condition in a loop while doing no useful work.

• On a uniprocessor, busy waiting is especially wasteful:
  • the waiting thread consumes CPU time,
  • while the thread that could make progress may not get scheduled.
• Thus, CPU time is wasted without useful progress.

• The issue is not merely that there is a loop.
• The issue is that the waiting time is not bounded in the program logic.
• A pathological schedule can make the spinner waste arbitrary amounts of CPU time.

• The lecture gives an example:
  • one process is spinning,
  • the other process, which would resolve the condition, is not scheduled,
  • perhaps because the spinner has higher priority.
• Then the system may effectively stall.

• Replacing the infinite loop with a fixed finite delay does NOT solve the correctness problem.
• For any fixed number of wait steps, one can construct a schedule where that delay is insufficient.
• Therefore, “pause a bit and hope” is not a correct synchronization strategy.

• For the synchronization problems in this course, busy waiting is not considered a proper solution.

• The lecture interprets the note protocol as a crude locking scheme:
  • leaving a note = locking the resource,
  • removing the note = unlocking the resource.

• The protected resource is not literally “the fridge note”.
• Rather, the lock protects:
  • the consistency of the shared decision state,
  • the correctness condition “do not buy more than one bottle”.

• Without proper primitives, the lock itself may be manipulated incorrectly.
• Therefore, one needs a more robust abstraction.

• Several proposed fixes effectively ask for something like:
  • “check and set together”,
  • “look and claim together”,
  • “take a note and inspect state in one indivisible step”.

• Hardware often offers such low-level atomic instructions, for example:
  • load/store variants,
  • fetch-and-increment,
  • test-and-set,
  • compare-and-exchange / CAS.

• Different architectures provide different instructions and semantics.
• x86, ARM, and other architectures differ substantially.
• Correct use therefore requires detailed hardware knowledge.

• On a uniprocessor, concurrency from the OS scheduler arises through interleaving.
• Interleaving is caused by preemption, and preemption is triggered by interrupts.
• Therefore, on a uniprocessor:
  • execution between two interrupts is non-interleaved.

• If the kernel temporarily disables interrupts, then the currently running code will not be preempted.
• This can make a short sequence of instructions effectively atomic on a uniprocessor.

• Interrupts must not be disabled for too long.
• Otherwise the system becomes unresponsive to the environment.
• Examples of negative consequences mentioned in the lecture:
  • delayed reaction to device events,
  • increased latency,
  • poor interactivity,
  • bad behavior in safety-critical systems,
  • networking delays,
  • generally reduced responsiveness.

• Disabling interrupts on one core does not stop another core from accessing shared memory.
• Therefore, this is not a general solution on multiprocessors.

• Disabling interrupts can be used very carefully for extremely short kernel-critical sequences.
• But it is not the general synchronization solution.
• Proper synchronization abstractions are still needed.

• Available atomic instructions vary from machine to machine.

• Even similarly named instructions may have different semantics across architectures.

• If synchronization is built directly on raw atomic primitives, one often ends up with busy waiting.
• The scheduler is unaware of what the process is waiting for.

• The OS should provide a higher-level, portable abstraction with predictable semantics.

• Semaphores were introduced by Dijkstra in 1962.

• A semaphore is essentially an integer counter together with two atomic operations.

• The lecture mentions common alternative terminology:
  • P is also called:
    • wait,
    • down,
    • acquire.
  • V is also called:
    • signal,
    • up,
    • release.

• They provide:
  • portable semantics,
  • a simple abstraction,
  • efficient implementation inside the OS,
  • no need for user-level busy waiting.

• If a thread cannot proceed in P, the OS can:
  • remove it from the ready queue,
  • put it onto a wait queue,
  • wake it later when the semaphore is signaled.
• This avoids wasting CPU cycles by spinning.

• The milk-buying problem becomes simple with a semaphore.
• Use a semaphore representing the right to enter the critical section.

• The correct initial value is:

  1
  

• Reason:
  • the first arriving process sees a positive value and proceeds,
  • the next one sees 0 and must wait.

• The code structure is essentially:

  P(s)
  check whether milk is present
  if not, buy milk
  V(s)
  

• The solution is:
  • symmetric,
  • short,
  • easy to reason about,
  • portable,
  • efficient when implemented by the OS.

• Values effectively restricted to:
  • 0
  • 1
• Main use:
  • mutual exclusion
• It behaves conceptually like an atomic boolean lock.

• Value is not restricted to 0 or 1.
• It can count how many times some event has occurred.
• Main use:
  • condition synchronization
  • counting available resources or produced events.

• Binary semaphore:
  • protects critical sections.
• Counting semaphore:
  • records availability or occurrence of events.

• The lecture then moves to the producer-consumer pattern.
• Producer:
  • creates data.
• Consumer:
  • consumes/processes data.
• A canonical real-world example is the Unix pipe.

• Produced data must be stored in a finite set of buffers.
• Therefore synchronization is needed because:
  • a producer needs an empty buffer before producing,
  • a consumer needs a full buffer before consuming.

• The queues/lists of buffers are themselves shared state.
• Therefore, in addition to condition synchronization, we also need mutual exclusion so that the shared buffer lists are not corrupted.

• The lecture derives that three semaphores are needed:

• The lecture recommends clear names such as:
  • buffer_empty
  • buffer_filled
  • buffer_pool_mutex
• Especially, semaphores used for mutual exclusion should be named mutex to make code easier to understand.

• Let N be the total number of buffers.

• The producer conceptually does:
  1. get an empty buffer from the pool,
  2. store produced data into it,
  3. place the filled buffer into the pool of full buffers.

• Before taking an empty buffer, the producer must wait until one exists:

  P(buffer_empty)
  

• To remove an empty buffer from the shared pool, the producer must enter the critical section:

  P(buffer_pool_mutex)
  

• The producer now obtains a buffer from the shared empty-buffer pool.

• Once the producer has taken one private buffer out of the pool, it should release the mutex:

  V(buffer_pool_mutex)
  

• Because the actual data production may take a long time.
• Holding the mutex during production would unnecessarily serialize unrelated work by other processes.
• The critical section should be kept as short as possible.

• At this point the buffer is private to the producer.
• No other process can access it while it is outside the shared pool.
• Therefore this step does not require the mutex.

• To insert the filled buffer into the shared full-buffer pool:

  P(buffer_pool_mutex)
  

• Now the consumer can later obtain it.

• For a mutex-style semaphore, P and V often appear as a natural acquire/release pair around one critical section.
• For a counting semaphore, the P and V are often in different parts of the program:
  • one side waits for the event,
  • the other side signals that the event happened.
• This distinction is fundamental and frequently causes mistakes.

• No.
• Once the producer removes one buffer from the shared pool under mutex protection, that buffer is private to the producer until it is placed back into the shared structure.

• Because the actual work may be slow.
• Keeping the mutex would block other processes from accessing the shared pool even though they do not need the producer’s private buffer.
• This would unnecessarily reduce concurrency.

• This is done by the consumer when it finishes consuming a full buffer and returns it to the empty-buffer pool.
• The lecture stops before completing the consumer code, but clearly indicates that this is the consumer’s responsibility.

• The lecturer explicitly notes that this producer-consumer semaphore pattern is a standard pattern and a frequent source of mistakes in exams.
• It should be studied until the role of each semaphore is completely clear.

• Once state is shared, correctness depends on interleaving and hardware guarantees.

• If correctness depends on “who gets there first”, the system is likely broken.

• Correct synchronization relies on operations that cannot be interrupted midway.
• But raw atomic hardware operations are too low-level and too machine-dependent to use directly as the main abstraction.

• It wastes CPU and interacts badly with scheduling.

• The operating system should hide hardware complexity behind predictable synchronization abstractions.

• binary semaphores solve mutual exclusion,
• counting semaphores solve condition synchronization.

• It requires both:
  • condition synchronization (empty/full buffers),
  • mutual exclusion (protecting the shared buffer pool).

• First specify correctness:
  • safety,
  • liveness/progress,
  • mutual exclusion.
• Only then design the synchronization mechanism.