PTHREAD_MUTEX_SHARED on Cygwin

PTHREAD_MUTEX_SHARED on Cygwin

[Thomas Koenig]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]


Hi,

there is a branch of gfortran for implementing coarrays based on a
shared memory implementation instead of MPI, the devel_coarray/native
branch.

I tried it out on Cygwin, but it doesn't work there (hangs on the
first sync).

The branch uses pthread mutexes and condition variables
with PTHREAD_PROCESS_SHARED for synchronization between processes.

I also ran the attached test program, which gave the output

pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_SHARED)failed: No error


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?

If PTHREAD_PROCESS_SHARED does not work, are there known workarounds?

Best regards

	Thomas

[-- Attachment #2: s.c --]
[-- Type: text/x-csrc, Size: 971 bytes --]

#include <errno.h>
#include <fcntl.h>
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <unistd.h>

#define ERR_CHK(x) \
  do { \
	if (x) { \
	  perror(#x "failed"); \
	  exit(1); \
	} \
  } while (0)

int
main(int argc, char **argv) {
  pthread_condattr_t cattr;
  pthread_mutexattr_t mattr;
  pthread_mutex_t *m;
  pthread_cond_t *c;
  void *mem;

  ERR_CHK((mem = mmap(0, 0x1000, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0)) == MAP_FAILED);

  m = mem;
  c = mem + 0x800;

  ERR_CHK(pthread_mutexattr_init(&mattr));
  ERR_CHK(pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_SHARED));
  ERR_CHK(pthread_mutex_init(m, &mattr));
  ERR_CHK(pthread_mutexattr_destroy(&mattr));

  ERR_CHK(pthread_condattr_init(&cattr));
  ERR_CHK(pthread_condattr_setpshared(&cattr, PTHREAD_PROCESS_SHARED));
  ERR_CHK(pthread_cond_init(c, &cattr));
  ERR_CHK(pthread_condattr_destroy(&cattr));

  printf("Success\n");

  return 0;
}

Re: PTHREAD_MUTEX_SHARED on Cygwin

[Brian Inglis]

On 2021-01-09 11:23, Thomas Koenig via Cygwin wrote:
> there is a branch of gfortran for implementing coarrays based on a
> shared memory implementation instead of MPI, the devel_coarray/native
> branch.
> 
> I tried it out on Cygwin, but it doesn't work there (hangs on the
> first sync).
> 
> The branch uses pthread mutexes and condition variables
> with PTHREAD_PROCESS_SHARED for synchronization between processes.
> 
> I also ran the attached test program, which gave the output
> 
> pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_SHARED)failed: No error
> 
> 
> 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?

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

https://sourceware.org/git?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/thread.cc;hb=HEAD#l16

https://sourceware.org/git?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/thread.cc;hb=HEAD#l1889

> 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.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: PTHREAD_MUTEX_SHARED on Cygwin

[Marco Atzeri]

On 09.01.2021 19:23, Thomas Koenig via Cygwin wrote:
> 
> Hi,
> 
> there is a branch of gfortran for implementing coarrays based on a
> shared memory implementation instead of MPI, the devel_coarray/native
> branch.
> 
> I tried it out on Cygwin, but it doesn't work there (hangs on the
> first sync).
> 
> The branch uses pthread mutexes and condition variables
> with PTHREAD_PROCESS_SHARED for synchronization between processes.
> 
> I also ran the attached test program, which gave the output
> 
> pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_SHARED)failed: No 
> error
> 
> 
> 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?
> 
> If PTHREAD_PROCESS_SHARED does not work, are there known workarounds?
> 
> Best regards
> 
>      Thomas
> 

some time ago I worked on a similar shared memory issue on Fortran

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47030

but I was never able to fully follow-up
and it seems my patch was incomplete, and caused

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89079

so it is possible that this issue is also impacting
your problem.

Regards
Marco

Re: PTHREAD_PROCESS_SHARED not implemented (was PTHREAD_MUTEX_SHARED on Cygwin)

[Brian Inglis]

On 2021-01-09 12:58, Brian Inglis wrote:
> On 2021-01-09 11:23, Thomas Koenig via Cygwin wrote:
>> there is a branch of gfortran for implementing coarrays based on a
>> shared memory implementation instead of MPI, the devel_coarray/native
>> branch.
>>
>> I tried it out on Cygwin, but it doesn't work there (hangs on the
>> first sync).
>>
>> The branch uses pthread mutexes and condition variables
>> with PTHREAD_PROCESS_SHARED for synchronization between processes.
>>
>> I also ran the attached test program, which gave the output
>>
>> pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_SHARED)failed: No error
>>
>>
>> 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?
> 
> The function is supported but that parameter is not implemented or tested and 
> returns EINVAL:
> 
> https://sourceware.org/git?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/thread.cc;hb=HEAD#l16 
> 
> 
> https://sourceware.org/git?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/thread.cc;hb=HEAD#l1889 
> 
> 
>> 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.

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

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

Presumably your goal is to support or disqualify gfortran coarrays:

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

For more about Windows limitations and alternatives see:

https://www.boost.org/doc/libs/1_75_0/doc/html/interprocess/sharedmemorybetweenprocesses.html#interprocess.sharedmemorybetweenprocesses.sharedmemory.emulation

and the internal page link target:

https://www.boost.org/doc/libs/1_75_0/doc/html/interprocess/sharedmemorybetweenprocesses.html#interprocess.sharedmemorybetweenprocesses.sharedmemory.windows_shared_memory

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: PTHREAD_PROCESS_SHARED not implemented (was PTHREAD_MUTEX_SHARED on Cygwin)

[Brian Inglis]

On 2021-01-09 15:16, Brian Inglis wrote:
> On 2021-01-09 12:58, Brian Inglis wrote:
>> On 2021-01-09 11:23, Thomas Koenig via Cygwin wrote:
>>> there is a branch of gfortran for implementing coarrays based on a
>>> shared memory implementation instead of MPI, the devel_coarray/native
>>> branch.
>>>
>>> I tried it out on Cygwin, but it doesn't work there (hangs on the
>>> first sync).
>>>
>>> The branch uses pthread mutexes and condition variables
>>> with PTHREAD_PROCESS_SHARED for synchronization between processes.
>>>
>>> I also ran the attached test program, which gave the output
>>>
>>> pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_SHARED)failed: No error
>>>
>>>
>>> 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?
>>
>> The function is supported but that parameter is not implemented or tested and 
>> returns EINVAL:
>>
>> https://sourceware.org/git?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/thread.cc;hb=HEAD#l16 
>>
>>
>> https://sourceware.org/git?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/thread.cc;hb=HEAD#l1889 
>>
>>
>>> 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.
> 
> It looks like there was nothing on this between implementation circa 2002 and:
> 
> https://sourceware.org/pipermail/cygwin/2019-February/240178.html
> 
> Presumably your goal is to support or disqualify gfortran coarrays:
> 
> https://gcc.gnu.org/pipermail/fortran/2021-January/055542.html
> 
> For more about Windows limitations and alternatives see:
> 
> https://www.boost.org/doc/libs/1_75_0/doc/html/interprocess/sharedmemorybetweenprocesses.html#interprocess.sharedmemorybetweenprocesses.sharedmemory.emulation 
> 
> 
> and the internal page link target:
> 
> https://www.boost.org/doc/libs/1_75_0/doc/html/interprocess/sharedmemorybetweenprocesses.html#interprocess.sharedmemorybetweenprocesses.sharedmemory.windows_shared_memory 

Bit more discussion where Dave Korn suggests using Sys V IPC semaphores instead:

https://cygwin.com/pipermail/cygwin/2006-September/150304.html

which I believe requires running the cygserver daemon as a Windows service, 
using cygrunsrv as a Windows elevated admin process, possibly in a scheduled 
task at startup or logon.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: PTHREAD_MUTEX_SHARED on Cygwin

[Thomas Koenig]

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

Re: PTHREAD_PROCESS_SHARED not implemented (was PTHREAD_MUTEX_SHARED on Cygwin)

[Noel Grandin]

On 2021/01/10 12:16 am, Brian Inglis wrote:
> 
> For more about Windows limitations and alternatives see:
> 
> https://www.boost.org/doc/libs/1_75_0/doc/html/interprocess/sharedmemorybetweenprocesses.html#interprocess.sharedmemorybetweenprocesses.sharedmemory.emulation 
> 

For the specific case of inter-process mutexes, Windows already supports multiple processes accessing the same mutex:

https://docs.microsoft.com/en-us/windows/win32/sync/interprocess-synchronization

But presumably there would need to be a lot of bookkeeping by cygwin/newlib to provide POSIX semantics on top of that.