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
