This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Concurrency semantics of fork
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, libc-help at sourceware dot org
- Date: Mon, 9 Nov 2015 19:41:26 -0500
- 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>
On 11/09/2015 12:35 PM, Adhemerval Zanella wrote:
>
>
> On 03-11-2015 09:39, Florian Weimer wrote:
>> Does fork behave as if it performs an acquire load of the process memory
>> regions it duplicates?
>
> I believe this is open to implementation, although I curious to understand
> which scenario you are thinking where the memory semantics for the
> duplicated regions should take in consideration.
Assume a lockless malloc implementation and then fork. What guarantees does
the child have with regards to the state of the structures in such a malloc
implementation?
If COW behaves as if it was an acquire load of the process memory region it
duplicates then you can say something useful about the state of malloc
structures in the child that has a forked copy.
I think vfork and fork have to behave as full barriers. After such a full
barrier you can say something useful about the state of the child.
Cheers,
Carlos.