Date: Wed, 2 Dec 2009 20:03:41 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: freebsd-current@freebsd.org Subject: Re: process shared semaphores? Message-ID: <Pine.GSO.4.64.0912021957060.16008@sea.ntplx.net> In-Reply-To: <20091203003705.GA1769@grapeape1.cs.duke.edu> References: <4B16D802.6030904@cs.duke.edu> <Pine.GSO.4.64.0912021617070.16008@sea.ntplx.net> <20091203003705.GA1769@grapeape1.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2 Dec 2009, Andrew Gallatin wrote:
> Daniel Eischen [deischen@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0912021957060.16008>