= Private file mapping
{title2=MAP_PRIVATE}
With `MAP_PRIVATE`, <copy-on-write> initially reuses backing <page cache> contents. In our model, a private store raises a protection <page fault>, copies the affected <memory page> to a private <page frame>, installs a writable <page table entry> and retries. The other <memory page> can remain shared. This <page fault> needs no storage read.
In B's <private file mapping>, storing $x=99$ copies relative page 1, including its neighbor $y=8$. Next, A stores $x=11,y=12$ through its <shared file mapping>. After coordination outside the mapped data, B's shared reads give $(11,12)$, while its detached private page gives $(99,8)$. The untouched first <memory page> remains backed by the <file>; this is not a frozen snapshot of the whole <file>. Neither <page writeback> of shared contents nor <msync> publishes B's private 99. To save those private contents, the application needs a separate explicit <file> update.
\Image[/memory-mapped-file-sharing-private-write-timeline.png]
{title=Toy <shared file mapping> and <copy-on-write> timeline: visible shared changes precede the chosen durable completion; private changes remain separate}
Back to article page
