liveBook · Manning

Shared resource

As explained in Grokking Concurrency

A shared object is a data or resource object accessed by multiple concurrent execution threads.

A shared resource is data or another resource that multiple threads or concurrent tasks can access. Threads in one process use the same address space, so one thread’s changes are available to the others. But concurrent access can produce inconsistent updates or deadlocks, and the order of access is not fully controlled by the developer. section 4.7 section 13.1

When tasks need shared data:

  • Minimize shared resources and communication where practical; use synchronization when sharing cannot be avoided. section 9.10
  • Account for synchronization costs: locks can delay access, add overhead, and hinder scalability. section 9.10
  • Consider message-passing IPC instead of shared memory so tasks can work with their own data copies. section 9.10

MapReduce intermediate data

Map tasks can store intermediate data on a shared NAS volume for reduce tasks to access, even when tasks run on different machines. section 13.11

How Grokking Concurrency covers it

How deep it goes
Explains access hazards, synchronization costs, and alternatives, but does not provide synchronization implementation steps.
Examples
Uses a process address space shared by threads and a NAS volume for MapReduce intermediate data.
What you can do after
Evaluate when shared data needs synchronization and when message passing could avoid shared memory.
How it connects
Connects shared resources with threads, concurrent tasks, synchronization, locks, and message-passing IPC.

Also explained in

Compare how 3 books explain shared resource →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Grokking Concurrency. The section links point to the parts of the book it draws on.