When a fork() system call is issued, a copy of all the pages corresponding to the parent process is created, loaded into a separate memory location by the OS for the child process. But this is not needed in certain cases. Consider the case when a child executes an "exec" system call (which is used to execute any executable file from within a C program) or exits very soon after the fork(). When the child is needed just to execute a command for the parent process, there is no need for copying the parent process' pages, since exec replaces the address space of the process which invoked it with the command to be executed.

In such cases, a technique called copy-on-write (COW) is used. With this technique, when a fork occurs, the parent process's pages are not copied for the child process. Instead, the pages are shared between the child and the parent process. Whenever a process (parent or child) modifies a page, a separate copy of that particular page alone is made for that process (parent or child) which performed the modification. This process will then use the newly copied page rather than the shared one in all future references. The other process (the one which did not modify the shared page) continues to use the original copy of the page (which is now no longer shared). This technique is called copy-on-write since the page is copied when some process writes to it.

It seems that when either of the processes tries to write to the page a new copy of the page gets allocated and assigned to the process that generated the page fault. The original page gets marked writable afterwards.

My question is: what happens if the fork() gets called multiple times before any of the processes made an attempt to write to a shared page?

Right. The point is, it's the child process that is special, that has the job of copying if it tries to write to the shared page. Neither the parent nor the other children need know about the change if it is done correctly.
–
Charles StewartDec 11 '12 at 9:20

2

The child process is not that special. Both the child and the parent processes have the same set of pages read-only after the fork. As far as these pages are concerned, page handling is symmetrical.
–
jlliagreDec 11 '12 at 12:22

When the system preforms a fork, usually (this may depend on implementation) it also marks the pages as read-only, and marks the parent process as the master of these pages.
When trying to write to these pages, a page fault occurs and the OS takes over, copying the entire list of pages or just the changed ones (again, dependent on implementation), so the writing process will have a writable copy.
When there are multiple processes forked from the same one, when the "master" process writes to it's memory, the other processes get their equivalent pages copied.

which system does this? linux uses a copy-on-write implementation
–
braulioboOct 10 '14 at 15:32

That is how the copy-on-write works...
–
David KohenOct 13 '14 at 13:02

@DavidKohen that's not how copy-on-write works in any version of it that I've ever heard of. There is no "master" process. If any single process writes the shared pages, its copy gets bumped to a private one while all the other processes continue to share it.
–
CeladaNov 13 '14 at 17:13

I think David Kohen is right to some point. This is one way to implement copy-on-write. The gist would be that with this marking, writing to that page would trigger a page-fault handler that would then take appropriate action, i.e. copy-on-write. Unfortunately this detail (which would be system-specific) is mostly irrelevant for the question. Keep in mind that CoW has two dimensions: the one visible to the process and the one of how the kernel might implement it.
–
0xC0000022LJul 1 at 7:45