It might be sufficient to have two distinct implementations of semaphores,
one for private semaphores (100% user-level) and one for shared
semaphores (with all operations going through syscalls). Then,
sem_wait and other operations just test the "shared" flag of the
semaphore and do either compare-and-swap as in my implementation or a
system call.
This makes semaphore maybe slightly less efficient than in the
implementation you outline, but that should still be reasonable.
I actually started to do this using System V semaphores to implement
shared semaphores. The big problem is with named semaphores (sem_open,
sem_unlink), which are not a good match for System V semaphores.
In particular, semctl(IPC_RMID) destroys a semaphore identifier
immediately, whether it's in use in other processes or not, while
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.
- Xavier Leroy