Date: Mon, 04 Feb 2002 22:10:43 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: smp@FreeBSD.ORG, Terry Lambert <tlambert2@mindspring.com>, Alfred Perlstein <bright@mu.org> Subject: Re: help with mutex_pool please? Message-ID: <XFMail.020204221043.jhb@FreeBSD.org> In-Reply-To: <200201201952.g0KJqY086603@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20-Jan-02 Matthew Dillon wrote:
>
>:
>:* Terry Lambert <tlambert2@mindspring.com> [020119 20:11] wrote:
>:> Alfred Perlstein wrote:
>:> >
>:> > I was going to convert some subsystems to use mutex pools...
>:> >
>:> > However if I apply this delta, a couple of seconds after boot I get
>:> > a lockup, sometimes the panic message is printed "sleeping with
>:> > mutex held"
>:> >
>:> > Any clues?
>:>
>:> Implied unlock on the two destroys you removed?
>:
>:Ah, thanks!
>:
>:--
>:-Alfred Perlstein [alfred@freebsd.org]
>
> That sounds like a misfeature, since there had better not be any
> contention with another process anyway when a mutex is in the process
> of being destroyed. The mutex destroy function should probably
> panic when it finds the mutex held and we should fix whatever other
> cases use the misfeature.
I think it is an optimization from BSD/OS due to lots of common code that does
this:
mtx_lock(&mumbo_struct->mb_mtx);
if (this_is_last_ref_and_I_need_to_die) {
mtx_destory(&mumbo_struct->mb_mtx);
free(mumbo_struct, M_MUMBO);
} else
mtx_unlock(...);
The optimization is that you avoid the unlock. It might be best to actually
keep these semantics and have mtx_destroy() panic if the mutex is marked
contested (not a very good way of testing this, but getting sched_lock and hten
reading the MTX_CONTESTED bit would catch most cases I would hope) and then set
mtx_lock to some invalid value that mtx_lock_sleep() can panic on. All this
would only be for the INVARIANTS case of course, and only if the mutex is
locked. If you don't allow this, then it's possible for some other code to
grab the mutex while you are destroying it which would lead to worse bugs I
think. At least we can detect the error condition if we keep the existing
semantics.
> -Matt
> Matthew Dillon
> <dillon@backplane.com>
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.020204221043.jhb>