Re: real POSIX.1b semaphores

Ulrich Drepper (
21 Nov 1996 00:29:16 +0100

"Theodore Y. Ts'o" <tytso@MIT.EDU> writes:

> True, we have to implement it. But we don't have to spend a lot of time
> getting it super fast, or particularily elegant. I'd concetrate on
> those parts of the POSIX.1b spec that are likely to be actually used by
> real applications.....

But I think that the named semaphores can be implemented on top of
the unnamed semaphores. The kernel should keep a list of the names
(the pseudo-filesystem) and return handle for a semaphore from the
common pool.

When I go back to my initial proposal:

sem_init() returns simply the next free semaphore in the buffer


sem_open() looks whether there is such a semaphore. If not and O_CREAT
is given is returns the next free semaphore, i.e., it implicitly
calls sem_init()

The functions which use semaphores behave the same.

(Please note that I don't talk anymore about a second pool for local
semaphores. Xavier pointed out that this is really stupid since it
would be slower than using a user-level only implementation.)

One point still not clear is whether it's worth to create a
pseudo filesystem for the named semaphores. I would vote for it
and the standard author encourage this use. It would allow easy
maintenance of the semaphore namespace. Keeping all names in a
plane namespace (i.e., treating / as a normal character) would
be simpler but once the semaphores are implemented I would think
hundreds of semaphores used at the same time is easily possible.
How do you like a directory with hundreds of entries? The POSIX
people gave us this mean of structurization so me should use it.

-- Uli
--------------. ,-. Rubensstrasse 5
Ulrich Drepper \ ,--------------------' \ 76149 Karlsruhe/Germany
Cygnus Support `--' `------------------------