Re: PTHREAD_MUTEX_SHARED on Cygwin

[Thomas Koenig <tkoenig@netcologne.de>]

I wrote:

>> Is it correct that PTHREAD_PROCESS_SHARED is not supported on
>> Cygwin?  Is it supported for condition variables, or is the fact
>> that it is reported as working an oversight?

First, thanks for the replies. I'll give sort of a compound answer.

Brian Inglis wrote:

 >> The function is supported but that parameter is not implemented or
 >> tested and returns EINVAL:

> If PTHREAD_PROCESS_SHARED does not work, are there known workarounds?

 > If you have the ability and time to work on this, one of the Cygwin
 > developers/maintainers may be able to assist.

Unfortunately, I have neither.  What I know about Cygwin is from a pure
user perspective, and what time I can deveote is soaked up by gfortran
in general and (currently) by the shared coarray branch in particular.

And in another mail:

 > It looks like there was nothing on this between implementation circ
 > 2002 and:

 > https://sourceware.org/pipermail/cygwin/2019-February/240178.html

That suggests it is not somthing trivially done, unfortunately.

 > Presumably your goal is to support or disqualify gfortran coarrays:

To be (a bit) pedantic, gfortran currently supports OpenCoarrays
(via -fcoarray=lib) for which you also need MPI. Not sure what
the status on Cygwin is for those.

My enquiry is about another implementation, which is based on
shared memory and on processes.

 > https://gcc.gnu.org/pipermail/fortran/2021-January/055542.html

The goal would be to support, of course, but this will not work
on current Cygwin.  Using SysV IPC or Windows directly could be
a solution, but at the moment the focus is on implementing the
many still missing features. The code is modular enough that
a drop-in solution for systems which do not support PTHTEAD_MUTEX_SHARED
can be added later without too much hassle.

Thanks for your pointers!

Best regards

	Thomas