From owner-freebsd-current@FreeBSD.ORG Thu Dec 3 01:03:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B7741065670 for ; Thu, 3 Dec 2009 01:03:46 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id C5D818FC0A for ; Thu, 3 Dec 2009 01:03:45 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id nB313fJL000913; Wed, 2 Dec 2009 20:03:41 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Wed, 02 Dec 2009 20:03:41 -0500 (EST) Date: Wed, 2 Dec 2009 20:03:41 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Andrew Gallatin In-Reply-To: <20091203003705.GA1769@grapeape1.cs.duke.edu> Message-ID: References: <4B16D802.6030904@cs.duke.edu> <20091203003705.GA1769@grapeape1.cs.duke.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: process shared semaphores? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 01:03:46 -0000 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