Shared memory lets multiple objects or processes access the same stored data. The practical question is whether sharing avoids an expensive copy without making changes or coordination difficult to manage. A NumPy view shares an array’s data within a process; Arrow’s Plasma server provides a shared store for separate local processes. section 4.1.1 section 7.5.2
Check whether arrays share data
Create a flipped view with `np.flipud(image_arr)` and an independent array with `np.flipud(image_arr).copy()`. `np.shares_memory(image_arr, flipped_view)` is true; the same check for the copy is false. Changing the original array also changes what the view sees, but not the copy. Views remake metadata rather than copying raw data; in the reported size sweep, view times stayed nearly flat while copy times rose sharply. `np.may_share_memory` offers a faster guess when an exact check is impractical. section 4.1.1
Share a table across processes
Start a local Plasma store with a one-gigabyte allocation and a UNIX socket. One process reads a CSV into an Arrow table and registers it with `client.put(table, object_id)`. Another process lists stored objects and retrieves the table with `client.get(object_id)`; a later-started consumer can find it even after the producer exits. Object IDs must be 20 bytes, so the example pads a process-based name before encoding it. section 7.5.2
plasma_store -s /tmp/fast_python -m 1000000000
The store command shows the socket path and memory allocation that the separate processes use. section 7.5.2
Do not assume shared memory is the first fix for slow multiprocessing. In a message-passing map-reduce experiment, increasing chunk size from 1 to 1,000 reduced runtime from 114.2 to 3.1 seconds. That measures chunking, not a shared-memory speedup. Naive shared-memory and low-level-lock designs are cautioned against because complex parallel communication is difficult to debug. section 3.4.4 section 3.6
