Messages in this thread | | | From | Doug Siebert <> | Subject | Fast Userspace Mutexes (futex) vs. msem_* | Date | Fri, 8 Mar 2002 00:15:52 -0600 (CST) |
| |
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/
| |