Platform‑dependent visibility of external edits in numpy.memmap mode='r+'

Answer

Neither Linux nor Windows reliably reflects external modifications to the backing file of a numpy.memmap opened with mode='r+' in the existing array view. The timing of reads after an external write only matters after you invalidate or recreate the mapping; immediate reads will see stale data.

Confirmed facts

• On Linux, NumPy’s memmap uses the system mmap() call. The mapping is created with private‑copy semantics, so changes made to the file by another process are not propagated to the existing view.
• On Windows, NumPy uses CreateFileMapping/MapViewOfFile with write access. The Windows memory manager similarly does not auto‑sync the user‑mode view with inter‑process file changes.
• Both platforms require the mapping to be dropped and re‑established (or the pages invalidated via msync with MS_INVALIDATE on POSIX) before updated file contents become visible.
• NumPy does not expose a built‑in API to invalidate or reload a memmap; you must close the current object and create a new np.memmap instance pointing to the same file.

Steps to guarantee synchronization

1. Perform the external write to the file (e.g., from another process or via raw I/O).
2. Close the existing memmap: del mmap_obj or let it go out of scope.
3. Re‑create the memmap with the same path and mode: mmap_obj = np.memmap(path, dtype=..., mode='r+', shape=...).
4. After this step, reads will reflect the external changes.

Likely explanation

The underlying OS memory‑mapping mechanisms do not automatically propagate inter‑process file modifications to existing user‑space views. NumPy’s thin wrapper preserves this behavior, so visibility depends on explicitly refreshing the mapping.

Missing diagnostic detail

Could you confirm the NumPy version you are using? Versions prior to 1.16 may employ different mmap flags, which could affect the need for a full remap versus a simple msync‑based invalidation.