Date: Tue, 3 Apr 2001 11:13:04 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Garrett Rooney <rooneg@electricjellyfish.net> Cc: Alfred Perlstein <alfred@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/sys mbuf.h src/sys/kern uipc_mbuf.c Message-ID: <200104031813.f33ID4b58965@earth.backplane.com> References: <200104030315.f333FCX69312@freefall.freebsd.org> <20010403140457.B2952@electricjellyfish.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:On Mon, Apr 02, 2001 at 08:15:12PM -0700, Alfred Perlstein wrote:
:> alfred 2001/04/02 20:15:12 PDT
:>
:> Modified files:
:> sys/sys mbuf.h
:> sys/kern uipc_mbuf.c
:> Log:
:> Use only one mutex for the entire mbuf subsystem.
:
:I can see how this makes some things cheaper by allowing you to only lock a
:single mutex instead of several, but doesn't it also limit you to only a
:single thread using the mbuf subsystem at a time? Since mbufs are used in a
:fairly large number of places throught the system, wouldn't that be bad?
:
:I'm sure this has been thought through, I'm just trying to understand why this
:will be better in the long run. Isn't the goal to have fine grained locking,
:rather than single locks limiting access to subsystems?
:
:--
:garrett rooney Unix was not designed to stop you from
What about using the BSDI hash-table-of-mutexes idea? Where mutex
functionality is overloaded to some degree for any given subsystem.
This gives us sufficient parallelism without polluting system structures
with their own mutexes.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104031813.f33ID4b58965>