Date: Wed, 18 Sep 2002 23:10:26 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Alfred Perlstein <alfred@FreeBSD.org>, hackers@FreeBSD.org, Garrett Wollman <wollman@lcs.mit.edu> Subject: Re: sem_init help? Message-ID: <Pine.GSO.4.10.10209182258230.10568-100000@pcnet1.pcnet.com> In-Reply-To: <3D893833.D24384A3@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <synch.h> */ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10209182258230.10568-100000>