Concurrency semantics of fork

[Carlos O'Donell]

On 11/10/2015 07:10 AM, Adhemerval Zanella wrote:
> 
> 
> 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.

That doesn't change the question, it changes only when the reordering happens.
Assume you consider the pages distinct. They became distinct at some point,
perhaps as part of the fork call. At that point when they became distinct,
what kind of memory ordering is enforced at that transition?

If the act of the memory becoming distinct is treated as if it were an
acquire load of all the memory, then it the other thread doing the fork
creates a synchronize-with that allows the transfer of some important information
from just before the fork, and you can do so without using a lock since locks
can inherently cause problems in program ordering or deadlocks.
 
>>
>> 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?

Ignore how COW behaves in reality, and think simply of happens-before
relationships provided by acquire/release of the process memory.

The question remains: When the fork'd processes memory is accessed, what
relationship does it have with the memory in the parent process with respect
to language memory model?


Cheers,
Carlos.