Date: Wed, 18 Sep 2002 19:36:35 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: Alfred Perlstein <alfred@FreeBSD.org>, hackers@FreeBSD.org, deischen@FreeBSD.org, Garrett Wollman <wollman@lcs.mit.edu> Subject: Re: sem_init help? Message-ID: <3D893833.D24384A3@mindspring.com> References: <Pine.GSO.4.10.10209182143040.27827-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D893833.D24384A3>