Start here

Synchronization orders access to shared data. Communication moves bytes between protection domains. You often need both: for example shared memory plus mutexes, or pipes plus structured messages.

Synchronization vs communication

Mutexes, semaphores, and condition variables solve mutual exclusion and waiting for predicates in a shared address space. Pipes, sockets, and message queues transport data across processes; they imply kernel buffering and possibly serialization costs.

By the end of this page you should be able to

Give an example that needs synchronization but not bulk data movement.
Give an example that needs communication across separate address spaces.
Name one pitfall of shared-memory IPC.

Operating systems · Processes

Synchronization vs communication

Ordering vs moving data

TL;DR

Synchronization coordinates **ordering** of access to shared memory (mutexes, barriers). Communication moves **data** between address spaces (pipes, sockets, shared memory). They interact: you often communicate without extra copies using shared memory, but then you need synchronization primitives to avoid races.

Summary

Interview answers should crisply separate “protect shared state” vs “exchange bytes or fds.” Then give one example where both appear (producer-consumer with shared buffer + mutex).

Deeper narrative

Synchronization orders access to shared memory; communication moves data between address spaces. They interact, message passing APIs still use kernel locks; shared memory IPC needs user-level sync primitives to avoid races.

Mechanism (step by step)

Treat each step as a sentence in the story you tell on a whiteboard.

Identify sharing domain

Threads share VAS → mutex/atomics; processes default to separate VAS → pipes/shm.

Choose primitive

Mutex for mutual exclusion; semaphore for counting; condition vars for predicates.

Choose transport

Byte streams (pipe/socket), shared memory + offsets, or RPC frameworks atop both.

Compose policies

Timeouts, back-pressure, and failure modes differ between sync and comm layers.

Key insights

Each card is a compression of the lesson, use them as spaced-repetition prompts.

False dichotomy in practice

High-performance servers combine shared-memory rings with atomic indices, both domains at once.

IPC cost model

Syscall count, copies, and TLB effects dominate; choose shared memory when bandwidth matters and you can prove invariants.

Deadlocks live in synchronization

Communication channels rarely deadlock alone, cycles appear when locks and messages interleave.

Select/poll/epoll

These synchronize I/O readiness with your event loop, bridging communication readiness and scheduling.

Did you know?

Trivia with teeth: the kind of fact that changes how you reason about a design.

Message passing can avoid shared-memory races entirely by serializing ownership transfers (Erlang style): different tradeoff curve.

Unix domain sockets can pass **fd**s (SCM_RIGHTS): communication of capabilities, not just bytes.

Memory barriers are synchronization for hardware visibility, not the same as mutexes but related.

Common pitfalls

Where smart people still trip, read slowly.

Using sockets for everything

Serialization overhead; shared memory wins bandwidth but complicates lifetime.

Mutex on shared memory without process-shared attr

PTHREAD_PROCESS_SHARED required for robust mutexes across processes.

Glossary

Critical section

Code region that must execute atomically w.r.t. other concurrent actors.

Back-pressure

Thundering herd

Many threads wake and contend for one lock after a broadcast wakeup.

Interview follow-ups

When does message passing beat shared memory for performance?
How does `mmap` MAP_SHARED relate to synchronization?
What is the thundering herd problem in wakeup?

Callouts

Common mistake

Calling `send` on a socket is communication, not synchronization, unless you use it to serialize ownership protocol.

Walkthrough & deep dive

Left: practical “how would I use this?” threads. Right: slower, code-leaning explanations, open one panel at a time so the page does not feel like a wall of sameness.

Walkthrough

Two-minute answer

Explain how a Go channel over a mutex differs from a Unix pipe between processes.

Deep dive

Memory-mapped IPC

`mmap(MAP_SHARED)` maps the same physical pages into two VAS, fast, but needs mutex/semaphore for coherent updates.

Pipe vs shm sketch

Terminal

pipe: kernel buffer + syscall read/write
shm: shared PTEs + user-space atomics/mutex

Self-check

Misses here are cheap; misses in an interview are not. Treat wrong answers as a patch list for tomorrow.

1A mutex primarily provides…

2A Unix pipe is primarily…

3Shared memory without sync is unsafe because…