Date: Mon, 4 Feb 2002 20:32:19 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: John Baldwin <jhb@FreeBSD.org> Cc: smp@FreeBSD.org, Terry Lambert <tlambert2@mindspring.com>, Alfred Perlstein <bright@mu.org> Subject: Re: help with mutex_pool please? Message-ID: <200202050432.g154WJ005060@apollo.backplane.com> References: <XFMail.020204221043.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
: 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.
Do you know of any other subsystems that depend on this behavior?
-Matt
Matthew Dillon
<dillon@backplane.com>
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?200202050432.g154WJ005060>