Date: Fri, 27 Apr 2007 11:07:39 -0700 From: Julian Elischer <julian@elischer.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-hackers@freebsd.org, Hans Petter Selasky <hselasky@c2i.net> Subject: Re: msleep() on recursivly locked mutexes Message-ID: <46323BEB.1020404@elischer.org> In-Reply-To: <200704271739.l3RHdG7a009988@apollo.backplane.com> References: <200704262136.33196.hselasky@c2i.net> <46311708.5030002@elischer.org> <200704270753.05438.hselasky@c2i.net> <200704271739.l3RHdG7a009988@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote: > 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. [description of DFLY spinlocks removed for brevity] > > 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. Actually Matt, I don't think there is much argument here.. It has come to the time where locking needs a big broom, and I suspect that there will be such a broom activated at BSDCan. There is some work going on (by john and others) to 'unify and sanitise' the locking. We'll see where it goes. Or is that wax and hot water?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46323BEB.1020404>