Robust Mutexes is an effort that steams out of the OSDL's Carrier Grade Linux working group to provide Linux with full-POSIX compliant locking and synchronization primitives, as well as to provide important features needed by Telecom Equipment Manufactures that other vendors, such as Solaris, provide.

In a nut-shell, this means priority inheritance, priority protection, complex deadlock detection, real-time support and mutex robustness.

Sep 12th 2005: Moved most (but glibc) to mercurial (and hosted them in a low-b/w DSL line...). However, merging is now bounds easier and faster. Undergoing a lot of changes in the user level API--the glibc tree has been broken for a while

Feb 11th 2005: CVS repositores, documentation and WWW stuff updated. Took a long time, but finally I got the time to do it. Next step: putting all the patches and stuff that I got together and integrating it into the repo.

The code can be obtained straight from the mercurial and CVS repositories:

$ export CVSROOT=:pserver:cvsanon@cvs.osdl.org/repos
$ cvs login #password is cvsanon
$ cvs co -d fusyn+rtnptl -l -r fusyn___branch \
> robustmutexes/fusyn+rtnptl
$ cd fusyn+rtnptl
$ cvs up -d -r rtnptl___branch rtnptl
                    

We have a document explaining why we think this patch is needed and the rationales behind the needs; see it at linux/Documentation/fusyn-why.txt once the patch is applied.

We presented at OLS 2004; the presentation slides and the paper are very up to date in explaining some of the guts of the implementation... OLS 2004 slides [pdf, openoffice, ppt] and paper [pdf].

Check out linux/Documentation/fusyn.txt in the patch (warning, it is a wee outdated in some areas); it explains the gory technical details with some philosophical wanderings in the middle. As well, Solari's man pages for pthread_mutex_lock() and friends help too (note our interface is kind of more flexible, we plan to provide full backwards compatibility). The man pages for the system calls fusyn provides are here (linux/Documentation/fusyn).

Huh? yep, screenshots; when you run some of the tests as it says in the README [piping the output through do-plot], you should get graphs of how the priority inheritance is working.

In all of them, each thread is just an empty infinite loop counting iterations. The TL thread runs in CPU1 (as a reference on progress vs time--not thatneccessary); the rest in CPU0. the TP thread has higher priority than TF. TB has higher prio than TP and TF. When TP runs, it stops every now and then to let TL run (so the slopes will be TL > TP > TF). Now, when TB runs, it tries to lock the fulock that TF owns and boosts it, so TP's slope goes down to nil).

We have a mailing list hosted at the OSDL developer site; not much traffic, though. Feel free to join.

It has been behaving pretty well lately; in case you find any, or if you have any feature request, we'd love if you can let us know (to any of the ones to blame), or log it to OSDL's developer bugzilla under the Robust Mutexes component.

Blame it on the knights that say nih! (or on the unladden swallows)

Actually that'd be Iñaky Pérez-González for the kernel part (the fusyn stuff), Boris Hu for the NPTL integration, David P. Howell for the ia64 bits and testing everywhere, Rolla Selbak, Salwan Searty and Adam Li for hammering the code left and right (so if you find a bug, we screwed up and they missed it :)

However most of this contacts have moved on, so feel free to contact Iñaky.

© 2002-2004 Intel Corporation, distributed under the terms of the GNU Public License, v2.0 or later.

OSDL for providing this space.