COMP30023 · Computer Systems
Interprocess Communication and Synchronization
Weeks 2-3 cover how cooperating processes and threads coordinate: race conditions on shared data, the critical-region problem, and the ways to achieve mutual exclusion — from naive lock variables and strict alternation to the atomic test-and-set-lock and blocking/yield approaches. Defining a race condition precisely and showing an interleaving that breaks a shared update, plus naming hazards like starvation, busy waiting and priority inversion, are standard exam items.
What this chapter covers
- 01IPC mechanisms (shared memory, pipes, files, sockets, signals) and the course focus on avoiding race conditions
- 02Race condition: outcome depends on the timing/order of execution of accesses to a shared resource
- 03Critical region and mutual exclusion; the four conditions a good mutual-exclusion solution must satisfy
- 04Why a naive lock variable fails: a context switch between the test and the set lets two threads enter
- 05Busy waiting and its costs (wasted CPU, priority inversion); strict alternation and why it violates condition 3
- 06Test-and-Set Lock (TSL): the atomic test-and-set instruction and the enter_region/leave_region pattern
- 07Blocking/yield alternatives to busy waiting; the yielding mutex that reschedules instead of spinning
- 08Hazards named in the exam: starvation, busy waiting, priority inversion (deadlock is flagged non-examinable)
A lost update from a race condition
- +1The statement count = count + 1 is not atomic: it is load count → register, add 1 to register, store register → count. A context switch can occur between any of these steps, which is what makes the result depend on timing (a race condition).
- +1Thread A loads count (= 0) into its register, then the scheduler context-switches to Thread B before A stores.
- +1Thread B loads count (= 0), adds 1, and stores count = 1, then finishes. The scheduler resumes Thread A, whose register still holds the stale value 0; A adds 1 to get 1 and stores count = 1. Two increments ran but one was lost — the final value is 1, not 2.
- +1The fix is mutual exclusion: make the load-add-store sequence a critical region protected so that only one thread executes it at a time — for example a lock/mutex built on the atomic test-and-set-lock instruction. Then the second thread's update starts only after the first has stored, so the result is 2 regardless of scheduling.
Key terms
- Race condition
- A bug where several processes/threads access a shared resource and the outcome depends on the timing or order in which their operations interleave, so results are indeterminate and can differ run to run.
- Critical region
- The part of a program where a shared resource is accessed. Correctness requires that no two processes are ever inside their critical regions for the same resource at the same time.
- Mutual exclusion
- The guarantee that at most one process/thread is executing in a critical region at any instant. A good solution also must not assume CPU speeds/counts, must not let a process outside its critical region block another, and must not starve any process.
- Test-and-Set Lock (TSL)
- A hardware instruction that atomically copies a lock variable into a register and writes a non-zero value to the lock in one indivisible step. It underpins a correct spinlock: loop on TSL until the lock reads free (enter_region), and set the lock to 0 to leave (leave_region).
- Busy waiting
- Repeatedly looping to test whether a lock is free instead of sleeping. It wastes CPU cycles and can cause priority inversion; the alternative is to block/yield the CPU to another thread while waiting.
- Priority inversion
- A high-priority process busy-waits for a lock held by a low-priority process that never gets scheduled (the high-priority one always runs), so the lock is never released and the high-priority process loops forever.
Interprocess Communication and Synchronization FAQ
What exactly is a race condition?
A race condition occurs when two or more processes or threads access a shared resource and the final result depends on the exact order in which their steps interleave. Because an operation like count = count + 1 is really load-add-store (not atomic), a context switch in the middle can cause a lost update. The defining phrase to use in the exam is 'the outcome depends on the timing/order of scheduling', which distinguishes it from deadlock, starvation and mutual-exclusion violations.
What makes a good mutual-exclusion solution?
Four conditions: (1) no two processes are inside their critical regions at once; (2) no assumptions about CPU speed or the number of CPUs; (3) no process running outside its critical region may block another; (4) no process waits forever to enter (no starvation). Strict alternation fails condition 3 because a process outside its critical region can still block the other via the turn variable, and a naive lock fails condition 1 because of the test-then-set window.
Why does a simple lock variable not work?
Because testing the lock and setting it are two separate operations. A thread can see lock == 0 (free), and before it writes lock = 1 a context switch lets a second thread also see lock == 0 and enter — now both are inside the critical region. The fix is an atomic test-and-set-lock instruction that does the read and the write as one indivisible step, closing that window.
What is priority inversion and how is it related to busy waiting?
Priority inversion happens when a high-priority process busy-waits for a lock held by a low-priority process. Because the high-priority process is always runnable (spinning), the scheduler never runs the low-priority holder, so it never releases the lock and the system stalls. It is a hazard of busy waiting under priority scheduling; blocking/yielding instead of spinning, or briefly raising the holder's priority, avoids it.
Can AI help me with synchronization problems in COMP30023?
Yes, as a study aid. Sia can construct a race-condition interleaving for you, explain why TSL is atomic, contrast busy waiting with blocking, or walk through the yielding-mutex lock family step by step, checking your reasoning. It helps you learn the method and rehearse exam-style answers; it does not do your graded assessment, and University of Melbourne academic-integrity rules apply.
Exam move
Synchronization is conceptual short-answer territory, and it appears in the mid-semester test (operating-systems half) and the final exam, so practise producing precise definitions and one concrete interleaving under time pressure. Be able to define a race condition in the 'depends on scheduling order' form, list the four mutual-exclusion conditions, and show why a naive lock and strict alternation each fail. Write out the TSL enter_region/leave_region pattern and explain what 'atomic' buys you, then contrast busy waiting with blocking/yield and name the hazards (starvation, priority inversion) each can cause. Note that deadlock is flagged non-examinable, so do not over-invest there. Rehearse one worked interleaving until it is automatic; this material also underpins the concurrency you meet in the C projects, so it compounds toward your WAM.
Working through Interprocess Communication and Synchronization in COMP30023? Sia is AskSia’s AI Computer Science tutor — ask any COMP30023 Interprocess Communication and Synchronization question and get a clear, step-by-step explanation grounded in how COMP30023 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
