Messages in this thread |  | | Subject | Re: real POSIX.1b semaphores | From | Ulrich Drepper <> | Date | 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
while
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 --------------. drepper@cygnus.com ,-. Rubensstrasse 5 Ulrich Drepper \ ,--------------------' \ 76149 Karlsruhe/Germany Cygnus Support `--' drepper@gnu.ai.mit.edu `------------------------
|  |