process shared semaphores?

[Daniel Eischen]

On Wed, 2 Dec 2009, Andrew Gallatin wrote:

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

We had this same discussion last time.  You have a
short memory, don't you?  :-) :-)

The sem_t in FreeBSD is a pointer to a malloc'd struct
(see sem_alloc() in libc/gen/sem.c).  A pointer to malloc'd
memory cannot be shared across processes (unless they are
all children I suppose).

-- 
DE