Re: process shared semaphores?

Daniel Eischen [deischen_at_freebsd.org] wrote:
> On Wed, 2 Dec 2009, Andrew Gallatin wrote:
> 
> >
> >The man page for sem_init(3) says:
> >
> >    A non-zero value for pshared specifies a
> >    shared semaphore that can be used by multiple processes, which this
> >    implementation is not capable of.
> >
> >Is this still correct?   I'm asking, both because it seems strange to
> >not return an error if the implementation does not support pshared
> >semaphores, and because the threads library seems to expect
> >it to work.  Eg:
> >
> >int
> >_sem_init(sem_t *sem, int pshared, unsigned int value)
> >{
> >       semid_t semid;
> >
> >       semid = (semid_t)SEM_USER;
> >       if ((pshared != 0) && (ksem_init(&semid, value) != 0))
> >               return (-1);
> ><....
> >
> >
> >So is the man page out of date, or is the userspace code future-proof
> >for when the kernel catches up?
> 
> The code should probably return -1 and ENOTSUP.
> 
> Why don't you use named semaphores if you want
> process shared (sem_open)?  Shouldn't those work?

To be honest, I didn't know they even existed.  I'm
mostly a driver guy, and know little about user-space.
I'm trying to keep up FreeBSD support on a project that
is being developed mainly on Linux.  I've suggested them
to our main developer.

In the meantime, I'd like to understand what's going on under the
hood, and why what we're doing now on Linux (semaphore resides in
shared memory allocated with shm_open) wouldn't work.  It looks like
it should work, since with pshared semaphores, it just passes
everything through to ksem*.  Is problem that the kernel doesn't
really know about different processes using it? Eg, it has only seen a
ksem_init() from the server, which did the sem_init(), and it needs
the ksem_open() to know about other processes using it?

Thanks,

Drew