Re: problem with mmap and fork()

[Doug Henderson <djndnbvg at gmail dot com>]

On Fri, 22 Feb 2019 at 17:01, Glyn Gowing <> wrote:
> I have a program (attached) that works correctly on my mac but does
> not work with Cygwin on Windows 10. I'm running the latest version of

> What happens in the buggy execution is that the child obtains a lock
> before the parent releases it. I'm using mmap and a pthread_mutex_t
> object along with fork(). Again, this exact code works correctly on my
> Mac running Mojave.

The problem is not with mmap() and fork(). The problem is with using
both fork() and pthread_mutex_*().

In Linux, and cygwin, the pthread_mutex appears to be a pointer to a
queue (maybe) located in writable (or copy-on-write) memory which
seems not to be shared between processes. This memory is common to all
pthreads (in each process), so pthread_mutex's will work for them, but
pthreads in another process will be using a different mutex.

Darwin (the mac's OS) is derived from NeXTSTEP, BSD, Mach, and other
free software projects, so it's implementation of pthreads may be
vastly or subtly different than the Linux and cygwin version,
resulting in different behaviour.

The "pthread_mutex_t" you create in shared memory, is just a pointer
(think a HANDLE) to the actual mutex data structure. I think you would
see identical results if the mutex was created in non-shared memory.

Search for "fork and pthread" on e.g. Google, to see some info about
mixing these features, and about the recommendations to use semaphores
for creating critical sections between processes vs using mutexes
between pthreads.

HTH
Doug
-- 
Doug Henderson, Calgary, Alberta, Canada - from gmail.com

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple