From owner-freebsd-arch Mon Nov 12 16:24:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id BA7CD37B405 for ; Mon, 12 Nov 2001 16:24:34 -0800 (PST) Received: (qmail 2691 invoked from network); 13 Nov 2001 00:24:34 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 13 Nov 2001 00:24:34 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200111122357.fACNvc507188@apollo.backplane.com> Date: Mon, 12 Nov 2001 16:24:28 -0800 (PST) From: John Baldwin To: Matthew Dillon Subject: Re: cur{thread/proc}, or not. Cc: freebsd-arch@FreeBSD.ORG, Robert Watson , Terry Lambert 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 On 12-Nov-01 Matthew Dillon wrote: >:http://www.freebsd.org/~jhb/patches/refcount.patch >: >:It's slightly different than this in that refcount_drop() returns a boolean > > Ok, I've read it. Ick. Could you reorgranize it a bit to do something > slightly different? > > Make sys/refcount.h provide a machine portable set of routines. Allow > the machine/refcount.h headers to override the portable set. This way > an architecture does *NOT* need to implement routines for yet another > header file (or duplicate a lot of code over and over again). Actually, if I add atomic_fetchadd(), the whole thing becomes MI and can just live in sys/refcount.h. > This business about INVARIANTS makes no sense to me. INVARIANTS should > not totally change the way the refcount API works. It certainly should > not result in different structures! If we are embedding ref counts > in every structure in the system simply setting or clearing INVARIANTS > blows up our compatibility, which is bad. It could use a static system-wide mutex for all I care. The invariants need the mutex so they can safely read the value for the purposes of the KASSERT's, that is all. A pool would be better than a single mutex possibly. My question is how does your pool work? Do you pick a mutex out of the pool at init time like the lockmgr locks work? Or do you use a hash on the object address? > Also, I don't see any reason to embed yet another mutex in a structure. > The ref count should be a simple int. Use a pool of mutexes. If you > like > I'll commit a set of generic pool mutexes that you can simply call. How > about that? Well, there are different ways of doing lock pools. :) How about something like this: /* * Returns lock for address 'ptr'. * mtx_pool_find(void *ptr) { } #define mtx_pool_lock(p) mtx_lock(mtx_pool_find((p))) #define mtx_pool_unlock(p) mtx_unlock(mtx_pool_find((p)) Then if a structure (like lockmgr locks or sx locks) wants to cache the lock pointer instead of doing the hash all the time, it can just do foo->f_lock = mtx_pool_find(foo); This actually isn't all that difficult, it just adds the ability to lookup and cache the mutex associated with an address. I would also like it under mtx_* so it's clear what type of locks are in the pool, but that's just me. :) > -Matt -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message