From owner-freebsd-hackers Wed Sep 18 20:10:33 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2430437B488; Wed, 18 Sep 2002 20:10:28 -0700 (PDT) Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3AAF43E75; Wed, 18 Sep 2002 20:10:27 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.3/8.12.1) with ESMTP id g8J3AQnh011881; Wed, 18 Sep 2002 23:10:26 -0400 (EDT) Date: Wed, 18 Sep 2002 23:10:26 -0400 (EDT) From: Daniel Eischen To: Terry Lambert Cc: Alfred Perlstein , hackers@FreeBSD.org, Garrett Wollman Subject: Re: sem_init help? In-Reply-To: <3D893833.D24384A3@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 18 Sep 2002, Terry Lambert wrote: > Daniel Eischen wrote: > > > The sem_init() function is used to initialise the unnamed > ^^^^^^^ > > > semaphore referred to by sem. The value of the initialised > ^^^^^^^^^ > > > > If the pshared argument has a non-zero value, then the > > > semaphore is shared between processes; in this case, any > ^^^ > > > process that can access the semaphore sem can use sem for > ^^^^^^^^***************^^^^^^^^^^^^^^^^^^ > > > performing sem_wait(), sem_trywait(), sem_post(), and > > > sem_destroy() operations. > > > > > > Only sem itself may be used for performing synchronisation. > ***************^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > The result of referring to copies of sem in calls to > > > sem_wait(), sem_trywait(), sem_post(), and sem_destroy(), is > > > undefined. > > > > Terry, your forgot to prefix that with "If the pshared argument is zero". > > Alfred's concerned with pshared != 0. > > How do you make it so you can access a semaphore, if you are not the > process which created it, or a child of a process which created it, > if the semaphore is unnamed? It's in a shared memory region. > In another posting, you said: > > | The sem_close() and sem_unlink() man pages make it even clearer > | that it has to remain around. > > The documentation makes it pretty clear that this is only true for > named semaphores, The call for unnamed semaphores is sem_destroy(): > > http://www.opengroup.org/onlinepubs/7908799/xsh/sem_destroy.html Right, I've read that. > If this can actually be shared by processes that are unrelated, e.g. > processes which did not inherit the semaphore in the same way that > file descriptors are inherited, with the sem_init() being the moral > sem_t equivalent of "close on exec", then the implication is that > they are (1) system global and (2) persistent. I don't like this > interpretation, because there are no interfaces defined to allow > iteration of all outstanding unnamed semaphores, and there are no > commands which defined to use such interfaces (e.g. the POSIX sem_t > equivalent of "ipcs" and "ipcrm"). The clear implication is that > these objects are resource tracked. > > It's also pretty clear that the existnace of the sem_open(), sem_close(), > and sem_unlink() interfaces are set up to implement a rendesvous, to > avoid passing "magic" data around. > > Basically, this implies either a process relationship, or, an even > more strict interpretation, a shared heap implementation. > > So, given all that... > > IMO, the existance of the "pshared = 1" in the sepcification implies > a resource-tracked value, whose references are known to the system > implementing it. This basically limits it to a parent process and > children of that parent process. I disagree with this interpretation. But anyways... Solaris defines a sem_t as: typedef struct { /* this structure must be the same as sema_t in */ uint32_t sem_count; /* semaphore count */ uint16_t sem_type; uint16_t sem_magic; upad64_t sem_pad1[3]; /* reserved for a mutex_t */ upad64_t sem_pad2[2]; /* reserved for a cond_t */ } sem_t; This is what ends up being stored in (shared) memory. Other sync objects like sema_t and rwlock_t have the same format. Mutexes and CVs are also structures whose size match what is allocated above (3*64 for mutex, 2*64 for CVs). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message