Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Sep 2002 21:40:36 -0400 (EDT)
From:      Daniel Eischen <eischen@pcnet1.pcnet.com>
To:        Alfred Perlstein <alfred@FreeBSD.org>
Cc:        hackers@FreeBSD.org, deischen@FreeBSD.org, Garrett Wollman <wollman@lcs.mit.edu>
Subject:   Re: sem_init help?
Message-ID:  <Pine.GSO.4.10.10209182104060.27827-100000@pcnet1.pcnet.com>
In-Reply-To: <20020919005959.GO86737@elvis.mu.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

You really need to look at all the man pages for this to get
a clear picture (and then spend some time re-reading them).

See if you can get to this link:

  http://www.opengroup.org/onlinepubs/007904975/toc.htm

You can register to read the online specification here if
the above link doesn't work:

  http://www.unix.org/version3/online.html

> little help here... :)

I don't know that you really have to track the semaphores
location, but you do need to track its references by processes
and decrement them when they exit without destroying/closing/
unlinking the semaphores.  If you don't track its location,
the worst that happens is that it hangs around in the kernel
until the referencing processes exit.

If the semaphore is shared, you can just use a process-wide
unique Id for it and place that Id in the shared memory
instead of a structure.  In the kernel, you can lookup the
Id and reference its kernel object.  For non-shared, you
can fill the first word with magic so that you know it's
not shared, and place the rest of the stuff below it (if
you want provide userland functions and optimize away the
system calls).

I admit I haven't fully read the spec on semaphores, so
don't take my suggestions as gospel.

I'd like to see a generic way of doing this.  We have to
support shared mutexes and condition variables also, so
it'd be nice to kill 3 birds with one stone.

-- 
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.10209182104060.27827-100000>