This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Concurrency semantics of fork
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Carlos O'Donell <carlos at redhat dot com>, libc-help at sourceware dot org
- Date: Tue, 10 Nov 2015 10:10:34 -0200
- 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>
On 09-11-2015 22:41, Carlos O'Donell wrote:
> 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 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.
>
> 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.
You mean 'unshare' all the possible COW pages for the process? Or regarding
internal GLIBC states regarding the process itself?
>
> Cheers,
> Carlos.
>