Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 05 Feb 2002 00:01:35 -0500 (EST)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Alfred Perlstein <bright@mu.org>, Terry Lambert <tlambert2@mindspring.com>, smp@FreeBSD.org
Subject:   Re: help with mutex_pool please?
Message-ID:  <XFMail.020205000135.jhb@FreeBSD.org>
In-Reply-To: <200202050432.g154WJ005060@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On 05-Feb-02 Matthew Dillon wrote:
>:        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/
> 
>     I think it would just be better to fix the cases that assume an unlock
>     on destroy and then KASSERT() that the lock is not being held on destroy
>     (i.e. panic).  Having the API do an auto-unlock-on-destroy is a bad idea.

I agree, but it makes for an easier debug case I think.  :-)

>     Do you know of any other subsystems that depend on this behavior?

Can't think of any off the top of my head.

>                                       -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.020205000135.jhb>