No support for sharing unnamed semaphores between processes through shared memory?

No support for sharing unnamed semaphores between processes through shared memory?

[Matt Sexton]

Hello,

I am attempting to port to Cygwin an application that synchronizes
between processes using unnamed semaphores in shared memory.  Both
processes have mapped the shared memory region, one process
initializes the semaphore, and both processes perform operations on
it.  Under Cygwin, the second process, which does not initialize the
semaphore, gets an EINVAL error when calling sem_post() on that
semaphore.  (There is no race condition between the initialization and
the posting of the semaphore by the different processes.)

Looking in /usr/include/semaphore.h, it appears that a sem_t is
typedef'ed as pointer to a struct.

In winsup/cygwin/thread.cc, semaphore::init appears to make the value
of the semaphore the result of a new operation.  This step would seem
to preclude the sharing the of the semaphore between processes, since
the pointer is only valid in the address space of the first process.

Is there no support for sharing unnamed semaphores between processes
using shared memory?  The man page under Linux documents this use case
and does seem to imply that it is part of the POSIX standard.

If the use case is not supported, what is the recommended work-around?
 Named semaphores?

Thank you,
Matt

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

Re: No support for sharing unnamed semaphores between processes through shared memory?

[Linda Walsh]

Matt Sexton wrote:
> Hello,
> 
> I am attempting to port to Cygwin an application that synchronizes
> between processes using unnamed semaphores in shared memory.  Both
> processes have mapped the shared memory region, one process
> initialize
----
	There's a cygwin process that you have to have running
for shared memory that "hosts" or holds on to the shared
memory.

I think it is the Cygwin cygserver....(but don't kill me if I'm wrong)...

Something needs to hang around and hold onto that shared memory, or windows
will recycle it.




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

Re: No support for sharing unnamed semaphores between processes through shared memory?

[Gregory M. Turner]

On 9/25/2012 2:03 PM, Linda Walsh wrote:
> Matt Sexton wrote:
>> Hello,
>>
>> I am attempting to port to Cygwin an application that synchronizes
>> between processes using unnamed semaphores in shared memory.  Both
>> processes have mapped the shared memory region, one process
>> initialize
> ----
>      There's a cygwin process that you have to have running
> for shared memory that "hosts" or holds on to the shared
> memory.
>
> I think it is the Cygwin cygserver....(but don't kill me if I'm wrong)...
>
> Something needs to hang around and hold onto that shared memory, or windows
> will recycle it.

It is cygserver -- in my limited experience, the shm works as advertised.

See http://cygwin.com/cygwin-ug-net/using-cygserver.html for gory 
details (actually, not so gory at all).

Remember to shut it down when running setup.exe, or if you rebase (this, 
because it's a regular cygwin process -- for the same reason, if you 
manage to wedge cygwin's pseudo-kernel, you may need to bounce the 
service, in addition to killing off all your other cygwin processes, 
before cygwin will so-to-speak "reboot" and unwedge).

-gmt


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

Re: No support for sharing unnamed semaphores between processes through shared memory?

[Corinna Vinschen]

On Sep 25 14:03, Linda Walsh wrote:
> Matt Sexton wrote:
> >Hello,
> >
> >I am attempting to port to Cygwin an application that synchronizes
> >between processes using unnamed semaphores in shared memory.  Both
> >processes have mapped the shared memory region, one process
> >initialize
> ----
> 	There's a cygwin process that you have to have running
> for shared memory that "hosts" or holds on to the shared
> memory.

That's not the problem here.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: No support for sharing unnamed semaphores between processes through shared memory?

[Corinna Vinschen]

On Sep 10 09:36, Matt Sexton wrote:
> Hello,
> 
> I am attempting to port to Cygwin an application that synchronizes
> between processes using unnamed semaphores in shared memory.  Both
> processes have mapped the shared memory region, one process
> initializes the semaphore, and both processes perform operations on
> it.  Under Cygwin, the second process, which does not initialize the
> semaphore, gets an EINVAL error when calling sem_post() on that
> semaphore.  (There is no race condition between the initialization and
> the posting of the semaphore by the different processes.)
> 
> Looking in /usr/include/semaphore.h, it appears that a sem_t is
> typedef'ed as pointer to a struct.
> 
> In winsup/cygwin/thread.cc, semaphore::init appears to make the value
> of the semaphore the result of a new operation.  This step would seem
> to preclude the sharing the of the semaphore between processes, since
> the pointer is only valid in the address space of the first process.
> 
> Is there no support for sharing unnamed semaphores between processes
> using shared memory?  The man page under Linux documents this use case
> and does seem to imply that it is part of the POSIX standard.

No, this case isn't supported, unfortunately.  The implementation of
pthreads in Cygwin is rather old, quite convoluted, and could probably
need a major revamp to support all POSIX requirements.

> If the use case is not supported, what is the recommended work-around?
>  Named semaphores?

Named semaphors should work in your scenario.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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