>> a lockmgr() option for "tell me if I could take this lock but don't
>> actually take it" would be even better.
> Wait, when is that a good idea?

Hinting.  I have no trouble imagining something like

	if (we could take all three locks)
		/* fast path */
		try to take all three locks, once each
		if success
			/* win */
			do stuff; unlock; return
		else
			back out any partial takes
		fi
	fi
	something slower but guaranteed deadlock-free

This assumes that checking is significantly cheaper than taking, so
it's worth checking all three before taking any (I don't know whether
this is true of our locks - it does occur to me that avoiding cache
operations on other CPUs of MP systems can be worthwhile, so if the
test doesn't involve cache invalidates elsewhere but taking does, it
could be a win - depending of course on how often the fast path
actually happens).

Debugging and other status queries (which actually will usually want
"tell me who's got this lock" instead, which is close to the same
thing).

Performance measurement (sampling to see how much of the time a given
lock is taken).

> If you don't take the lock when it's avaliable, then the validity of
> "I could take the lock" could be true when you examine it but false
> when you try to do something with it.

Yes.  So either you have to not try to take it (true of debugging and
performance measurement above) or make sure that you're prepared to
lose the race between testing and taking (hinting, above).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B