Loading page…
Master the fundamental concepts of inter-process communication through this focused micro-challenge.
You have read the whole brief, and the concepts above stay free on every task. Writing and running the code needs a plan.
Three hints are available for this task, revealed one at a time inside the code workspace so you can struggle productively before seeing them.
Every task includes starter code, theory, and hidden tests so you can implement and verify locally in the browser.
How it worksShared memory maps the same physical pages into multiple address spaces. After setup, processes communicate with loads and stores, not per-byte syscalls. Throughput beats pipes for large buffers.
SysV style:
shmget(key, size, IPC_CREAT) creates segmentshmat attaches at OS-chosen or fixed VAshmdt detaches; shmctl(IPC_RMID) removes idFor example, a 4 MB frame buffer attached in producer and consumer avoids copying through kernel buffers on every frame.
PostgreSQL's shared buffer pool and Chrome's GPU compositor both rely on SysV or POSIX shared memory for exactly the reason this task highlights: zero-copy access is dramatically faster than message-passing IPC for large, frequently-touched data. The task's warning about missing synchronization is a real operational hazard too, since orphaned shmget segments that outlive their creating process are a well-known source of production memory leaks, which is why ipcs/ipcrm exist as cleanup tools.
Before you call the implementation done, walk failure modes on purpose. Test empty structures, single-element edge cases, maximum concurrency, and errno paths that must not crash the program. OS code usually fails in production when happy-path tests pass but invariants break under contention or memory pressure.
Keep structures small and name fields after kernel counterparts when possible. That lets you read man pages and kernel source side by side while you work. Print observable events during development; remove noisy logs once tests pass reliably.
You will create a segment, attach in parent and child after fork, and exchange a structured message. The task asks you to measure latency vs an equivalent pipe transfer.
Pass messages between two processes through shared memory. Create a segment that both processes map, then fork. The child (producer) writes each input line into a ring buffer of fixed-size slots inside the segment. The parent (consumer) reads them straight out of the same memory: no copying through the kernel. With no kernel mediation, the two sides coordinate with head/tail counters, busy-waiting (spinning) when the ring is full or empty.
shmget(IPC_PRIVATE, …) + shmat, or with mmap(MAP_SHARED | MAP_ANONYMOUS), before fork, so both processes see it.K slots of 64 bytes (message length + text), a head counter (messages written), a tail counter (messages read), and a done flag.__atomic_store_n(..., __ATOMIC_RELEASE) / __atomic_load_n(..., __ATOMIC_ACQUIRE)) so the consumer never sees a counter before the slot data it covers.head − tail == K (full), copy the text into slot head mod K, then increment head. After the last message, set done.head > tail (or done and nothing left). Read slot tail mod K directly from shared memory, print it, then increment tail.reported flag. The producer waits for that flag, prints what it saw, and exits. The consumer then waitpids, detaches and removes the segment.The first line is slots K (1-8). Every following line is a message (at most 60 bytes; blank lines are messages too).
cLoading…
#n numbers the messages from 1, and the slot is (n − 1) mod K. The consumer must flush its output before setting reported, so the producer's line comes after it.
Input:
cLoading…
Output:
cLoading…
fork, and the consumer never reads the input itself.sched_yield() (or a short sleep) inside the wait loops, so a one-CPU sandbox still makes progress.Hidden tests cover a ring of 1 slot (strict hand-off), many more messages than slots, empty messages, and an input with no messages at all.