>
> One thing I'm wondering about is Linux's support for SYSV-style IPC
> (semop etc.). Those appear to be kernel-supported semaphores. Maybe
> the problem is not in the lack of kernel support, but could be fixed
> by using SysV semaphores instead? It would definitely be worth a try.
>
> On the other hand, aren't sysv semaphores optional when you configure
> your kernel? As such, there may be reason to not hardcode reliance
> on them in a glibc binary distribution(?) glibc could always
> test for it at run-time, though.
>
> I believe Xavier Leroy and/or the glibc people may be the right folks
> to ask. I've cc'd Xavier on this mail, maybe he has some insights
> as to what whether using semop would be an option.
>
I admit it's a long time since I used SysV semaphores. Obviously,
one of the reasons why they don't see widespread application is their
lack of proper reclamation when a process exits (-> ipcs, ipcrm etc.),
and the lack of a mechanism to create unique keys etc., etc.....
FWIW, I coded Matt's example using semaphores and I'm now seeing a
degradation of about 60 iters/ms vs. 600 iters/ms for the contended case.
Code is at http://www.cs.utah.edu/~gback/sem-test.c if anybody is interested.
Note that I've simply replaced the pthread_mutex_(un)lock() with a call
to semop(); this means that we're having a system call even in the
uncontended case. This is not what a sem-converted linux-thread would
look like. The 600->60 comparison only makes sense if one assumes that
every single attempt to lock is contended. Nevertheless, my gut feeling
is that even a linux-threads that would use Linux's SysV semaphores
would perform as poorly as the current signal-based implementation.
So, I believe that kernel support is indeed needed.
A websearch turned up an old proposal by Ulrich Drepper from 1996,
in which he proposes a /proc based mechanism to implement the POSIX.1b
semaphores. See
http://www.uwsg.indiana.edu/hypermail/linux/kernel/9611.2/0521.html
He's also suggesting ways to get around the resource reclamation and
namespace problems mentioned in my first paragraph. However, it appears
as though his proposal was never implemented.
- Godmar
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
