Memory-mapped file semantics

A shared file mapping makes updates available through mappings of the same underlying region and allows those updates to reach the file. A private mapping instead gives the process copy-on-write modifications that are not written back to that file. Private does not mean a permanently frozen snapshot of arbitrary concurrent external file changes; visibility of later changes to the underlying object has limits in the documented interface. If a reader needs a stable snapshot, use an explicit versioning or ownership protocol rather than inferring one from the word private.

The mapping offset normally must be aligned to the system page size. To access an unaligned logical file position, map from the preceding page boundary and add the position's offset within that page to the returned pointer. Include that prefix when sizing the mapping. A mapping can remain valid after its original file descriptor is closed, because the mapping holds its own reference. None of this makes a stale application pointer safe after munmap or authorizes access beyond the mapped length. Pointer lifetime still needs an owner.

Two processes sharing a page need synchronization that is valid for shared-memory communication. A reader must not observe a half-published multi-field record simply because the bytes are in a shared mapping. Language memory-ordering rules, process-shared synchronization, record formats, and recovery rules matter. Ordinary CPU cache coherence is not a replacement for these rules. A convenient design can write a complete new version and publish a reference using an appropriate protocol; a different design may require a journal or checksums. The chosen mechanism must match the actual concurrency and crash model.

Dirty shared pages can remain in the page cache before writeback. An explicit synchronization operation such as msync with MS_SYNC requests completion for the specified mapped range and can fail; check its result. It does not automatically supply multi-page transactional atomicity. File creation, extension, naming, and directory persistence may need additional filesystem-specific and fsync-related steps. Do not use munmap or close as a substitute for a documented durability protocol. A device that lies about flush completion also changes the failure model, independently of how the application addressed the bytes.

If another actor truncates a mapped file, a later access to a page beyond its current end can raise SIGBUS on Linux. A mapping is not a reservation preventing file-size changes by somebody else. The partial page at the end also has special rules; do not use bytes past the file's logical end as persistent scratch space. For safe data access, coordinate file replacement and truncation with the mapping users, validate record lengths against a stable file version, and plan how corrupt or incomplete records are rejected.

Explore writeback demand in two separate queue-lab runs. Press Reset, explicitly set both arrival three and service five, predict the initial four-job backlog drains after two model seconds, then Play or Step. Reset again, set both arrival five and service four, predict one-job-per-second growth from four, then Play or Step. Editing rates without Reset retains elapsed time and recomputes the initial-value model rather than preserving a live backlog. Treat jobs as equal normalized dirty-data batches solely to reason about imbalance. This does not simulate dirtying thresholds, msync completion, filesystem ordering, or crashes. Ask which acknowledgment would prove durable completion beyond finishing stores.