From owner-freebsd-smp Sat Jan 19 13:10:40 2002 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id DE67F37B41A for ; Sat, 19 Jan 2002 13:10:35 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g0JLA0J53749; Sat, 19 Jan 2002 13:10:00 -0800 (PST) (envelope-from dillon) Date: Sat, 19 Jan 2002 13:10:00 -0800 (PST) From: Matthew Dillon Message-Id: <200201192110.g0JLA0J53749@apollo.backplane.com> To: Julian Elischer Cc: Alfred Perlstein , smp@FreeBSD.ORG Subject: Re: help with mutex_pool please? References: Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org : :I have another question.... :what will the mutex pool give us as an advantage over other :techniques.? It allows you to avoid unnecessary structural bloat in a number of cases. Mutexes are used in many small structures (for example see kern_lock.c) where embedding a full mutex structure can easily double the size of the original structure. It is possible to reduce the strucural overhead to 0 with a pool mutex, though it is more common (and more understandable) if you embed at least a mutex pointer in the structure. Their use in kern_lock.c alone justifies the module, since what we had before was an ad-hoc mutex pool dedicated to kern_lock.c. Now it's generalized enough to be useful in a number of other subsystems. But, please note, I have no intention of allowing these pool mutexes to be generalized and bloated for use everywhere. They are strictly intended for leaf-mutex uses only. A normal mutex should be used for more complex cases. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message