* Daniel Eischen <[EMAIL PROTECTED]> [020918 18:40] wrote: > On Wed, 18 Sep 2002, Alfred Perlstein wrote: > > > > > Ok, any of you guys have a copy of the standards documents that > > describe the sem_* API? > > > > I have a question... > > > > What are the semantics of the sem_init when pshared is set to true? > > > > Like, if the process that created the semaphore exits, then what? > > Is it only valid for the life of the process that did the sem_init? > > Or am I going to have to do some nastyness to record the memory > > location where the semaphore is and track that page's allocation? > > My take on the spec is that as long as the semaphore can be > accessed by other processes, then it remains perfectly valid > regardless of whether the originating process exited or not. > > Here's a sem_init() blurb from Austin Draft 6: > > "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." > > The sem_close() and sem_unlink() man pages make it even clearer > that it has to remain around.
Wait, see, you're confusing named and un-named semaphores. I've got the named ones all set, it's the un-named ones I'm having trouble with. The only valid operations on un-named semaphores are: sem_init - to create it sem_wait/sem_trywait - to wait on it sem_destroy - to destroy it now here's the problem, one can basically stick a sem_t into a shared memory location, then one can share it amongst processes (provided pshared was set). However there's no requirement that these other processes do any form of "open" on the sem_t, hence I really have no way of tracking its usage other than by: a) auto-terminating it when the process that did sem_init exits. b) tracking the page where the actual sem_t was created until either it is reclaimed via sem_destroy or the page is free'd back to the OS. Unless I'm missing something here. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
