I'm a long-time lurker in linux-kernel, but the discussion about fast
userspace mutexes ("futexes") has piqued my interest. I made great
use of the msem_* (msem_init, msem_lock, msem_unlock) functions on HP-UX
in the mid 90s (HP-UX 9.01 and on) At the time, they were invaluable for
me, with 1000+ processes needing exclusive access to resources on a 50MHz
machine. Requiring a system call for this purpose would have been a major
performance hit (remember HP-UX's system calls are not nearly so light
weight as Linux's)
The direction that the futex implementation is going is looking a lot like
how they are implemented on HP-UX (as well as Tru64 and AIX) I am curious
though why the case of "what happens if the process holding the lock dies"
is considered unimportant by some people. It wouldn't be all that much
more work to "do it right" (IMHO) and handle this case. AFAIK, on HP-UX
the implementation kept a "locker id" and a linked list of waiters' lock
ids (to allow first come first served as well as handling the case of a
lock holder dying) There was an underlying system call that was made when
the userspace part in libc found the lock already held and waiting for the
lock was desired.
If the implementation does move further towards the msem_* standard, it
might make sense to just implement it as defined, and provide source
compatibility with existing applications on HP-UX, AIX, and Tru64 that
use it.
I'm not subscribed (I skim the hypermail archives on zork a couple times
a week, so please cc: me on comments for a faster response)
-- Douglas Siebert douglas-siebert@uiowa.edu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 15 2002 - 22:00:07 EST