From owner-freebsd-hackers Wed Sep 18 19:39:42 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 EA3CB37B4B5; Wed, 18 Sep 2002 19:39:37 -0700 (PDT) Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BB1243E6E; Wed, 18 Sep 2002 19:39:37 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0424.cvx21-bradley.dialup.earthlink.net ([209.179.193.169] helo=mindspring.com) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17rrE6-0003tL-00; Wed, 18 Sep 2002 19:39:34 -0700 Message-ID: <3D893833.D24384A3@mindspring.com> Date: Wed, 18 Sep 2002 19:36:35 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Eischen Cc: Alfred Perlstein , hackers@FreeBSD.org, deischen@FreeBSD.org, Garrett Wollman Subject: Re: sem_init help? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 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? 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 The argument to sem_unlink() is a name, not a semaphore, so it's not possible to use on an unnamed semaphore at all. The documentation of the sem_close() function states: The effects of calling sem_close() for an unnamed semaphore (one created by sem_init()) are undefined. Here is sample code for the Linux implementation; it has two rather profound problems, though: http://www.scs.carleton.ca/~barbeau/Courses/SETP/ALP/psemaphores.pdf The two prolbems are: 1) Linux doesn't support "pshared = 1", so it doesn't tell you anything about it. 2) There is a static declaration od a sem_t. I'm not sure that this is not actually intended to be a sized opaque type; they sem_init() on the address of the declared semaphore, which may actually be a bad thing. In the common implementation, it's: typedef HANDLE sem_t; Basically, that means you are passing arround an opaque pointer to a pointer to an object. This makes it impossible to statically declare one, or to have a pointer to one which is in a shared memory segment. 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. This interpretation also answers Alfred's other question, which I answered with my duplicate answer: when all processes with a reference to the semaphore exit, the semaphore is resource-tracked and is then destroyed. Given the URL reference to the X/Open documentation (above), it will be pretty easy to verify everything I've said by clicking over to the references -- my suggestion is to start with the semaphore.h reference, which is guaranteed to reference all the other objects, and to define the structure, if it is a non-opaque object (I believe the Linux use of a statically declarted sem_t object is an implementation specific assumption, and therefore invalid (even with the pointer-to-pointer interpretation of the HANDLE typedef). The lack of an iteration interface is pretty damning evidence, IMO. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message