Date: Fri, 27 Apr 2007 10:39:16 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org, Julian Elischer <julian@elischer.org> Subject: Re: msleep() on recursivly locked mutexes Message-ID: <200704271739.l3RHdG7a009988@apollo.backplane.com> References: <200704262136.33196.hselasky@c2i.net> <46311708.5030002@elischer.org> <200704270753.05438.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
The real culprit here is passing held mutexes to unrelated procedures
in the first place because those procedures might have to block, in
order so those procedures can release and reacquire the mutex.
That's just bad coding in my view. The unrelated procedure has no
clue as to what the mutex is or why it is being held and really has no
business messing with it.
What I did was implement spinlocks with VERY restricted capabilities,
far more restricted then the capabilities of your mutexes. Our
spinlocks are meant only to be used to lock up tiny pieces of code
(like for ref counting or structural or flag-changing operations).
Plus the kernel automatically acts as if it were in a critical section
if it takes an interrupt while the current thread is holding a spinlock.
That way mainline code can just use a spinlock to deal with small bits
of interlocked information without it costing much in the way of
overhead.
I made the decision that ANYTHING more complex then that would have to
use a real lock, like a lockmgr lock or a token, depending on the
characteristics desired. To make it even more desireable I also
stripped down the lockmgr() lock implementation, removing numerous
bits that were inherited from very old code methodologies that have no
business being in a modern operating system, like LK_DRAIN. And I
removed the passing of an interlocking spinlock to the lockmgr code,
because that methodology was being massively abused in existing code
(and I do mean massively).
I'm not quite sure what the best way to go is for FreeBSD, because
you guys have made your mutexes just as or even more sophisticated
then your normal locks in many respects, and you have like 50 different
types of locks now (I can't keep track of them all).
If I were to offer advise it would be: Just stop trying to mix water
and hot wax. Stop holding mutexes across potentially blocking procedure
calls. Stop passing mutexes into unrelated bits of code in order for
them to be released and reacquired somewhere deep in that code. Just
doing that will probably solve all of the problems being reported.
-Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200704271739.l3RHdG7a009988>