From owner-freebsd-arch Mon Nov 12 16:31:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id EA1DA37B405; Mon, 12 Nov 2001 16:31:20 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fAD0Unn07434; Mon, 12 Nov 2001 16:30:49 -0800 (PST) (envelope-from dillon) Date: Mon, 12 Nov 2001 16:30:49 -0800 (PST) From: Matthew Dillon Message-Id: <200111130030.fAD0Unn07434@apollo.backplane.com> To: Julian Elischer Cc: John Baldwin , Terry Lambert , Robert Watson , freebsd-arch@FreeBSD.ORG Subject: Re: cur{thread/proc}, or not. References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :weren't you just complaining that there were too many kinds of mutex? :I'm not sure how this fits under "reference counting API" : :ANyhow can you explain the idea of a pool mutex more clearly? A pool mutex is the BSDI concept, similar to the wait address when you tsleep(). You get the mutex via a rendezvous point which is an arbitrary pointer, and release it the same way. Just as with the wait address the pointer you pass is arbitrary. It need not represent any sort of structure and the structures you use need not embed any actual mutex. Instead the pool code would obtain a mutex out of a pool of mutexes based on a hash of the supplied pointer. pool_mtx_lock(void *ptr); pool_mtx_unlock(void *ptr); Pool mutexes could be used just about *everywhere* where a mutex is used in a non-reentrant fashion now. i.e. where you obtain a mutex, do a bunch of stuff that does not require obtaining any additional mutexes, and then release the mutex (which is how most mutexes are supposed to work anyway). There are two huge advantages to using pool mutexes: * No structural overhead. Zip. Zero. Zilch. Nada. * The mutex itself is stable storage, even if the address is not, so you can use it to verify the second pointer when you have a pointer to a (stable) structure containing a field which is a pointer to an (unstable) structure. while ((ptr = stable->pointer) != NULL) { pool_mtx_lock(ptr); if (ptr == stable->pointer) break; pool_mtx_unlock(ptr); } /* * stable->pointer, if not NULL, is now locked and itself stable * until you release the mutex */ There are two disadvantages: * Possible non-optimal cache mastership behavior. However, this is not a major disadvantage since it can be addressed by increasing the pool size. * Slightly greater overhead to calculate the hash index and obtain the address of the pool mutex before obtaining or releasing it. The pool mutex hash function would be something simple based on (int)ptr. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message