This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Concurrency semantics of fork
- From: Florian Weimer <fweimer at redhat dot com>
- To: adhemerval dot zanella at linaro dot org
- Cc: libc-help at sourceware dot org
- Date: Tue, 10 Nov 2015 21:21:02 +0100
- Subject: Re: Concurrency semantics of fork
- Authentication-results: sourceware.org; auth=none
- References: <56389D0F dot 5030305 at redhat dot com> <5640D977 dot 6090100 at linaro dot org> <56413D36 dot 7000409 at redhat dot com> <5641DEBA dot 1080702 at linaro dot org>
On 11/10/2015 01:10 PM, Adhemerval Zanella wrote:
> I am still trying to figure the issue you are raising: although COW does
> implicit sharing, my understanding is the pages are still independent
> regarding memory semantic. It should not stop memory reordering regarding
> any other process that might sharing the pages.
Assume that a thread does this:
unsigned a, b;
unsigned offset = rand ();
lock ();
a -= offset;
b += offset;
unlock ();
The process calls fork in another thread. In the child process, we peek
at the implementation of the lock (let's assume it's futex-based), and
we determine, based on the lock value, that the lock has not been
acquired. Looking at a and b, do we always observe that a + b == 0?
(Obviously, if the lock looks as if it has been acquired, all bets are off.)
Florian