> the POSIX 1003.1b sem_open/sem_unlink functions work as open/unlink,
> i.e. the semaphore is destroyed only when its refcount drops to 0.
>
> So, we certainly need a kernel-level implementation of 1003.1b
> semaphores, including named semaphores in a special filesystem, but
> not necessarily with semaphores being memory mapped as you described.
> Once this is done, LinuxThreads can take care of providing a faster,
> no-syscall implementation for private semaphores.
I have been following this discussion, and I have 1 suggestion I would
like to make. I think it would be good, if it is possible to do, to
have semaphores be real files in a real file system, rather than virtual
files in a special file system. My thinking is that most of the code
to do this is already in the filesystems, so we would probably have to add
a lot less than we would if the implemented a seperate FS. Also, the
access control would be taken care of by then normal FS access control
mechanisms, so if someone added a nonstandard feature to an FS, like access
control lists, then semaphores on this FS would automatically be able to
use it.
Its been a long time since I read the posix 4 book, so please forgive me
for not knowing the correct function names in this description. Also, it
is obvious to me that you two know this subject better than I, so
please take this description more as a question than as a proposal.
My thinking is that semaphores should act like this:
1) A process which wants to create a semaphore creates a 1 page file using
the semaphore name.
2) A process which wants to open a semaphore, opens this file and mmaps()
it. Thus all processes which have this semaphore open share a page
of memory.
3) A process which wants to use a semaphore for exclusive access to a
resource can use some form of atomic test and set operation on a memory
address in the shared page. If no other process has set this semaphore,
the process can continue, and nothing needs to happen in the kernel.
If another process has set the semaphore, then we need to sleep on the
lock. This is the part of the operation that I think will need kernel
support, though perhaps someone can think of a way to do it using
existing system calls.
Jim