Date: Mon, 12 Nov 2001 16:24:28 -0800 (PST)
From: John Baldwin <jhb@FreeBSD.org>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: freebsd-arch@FreeBSD.ORG, Robert Watson <rwatson@FreeBSD.ORG>, Terry Lambert <tlambert2@mindspring.com>
Subject: Re: cur{thread/proc}, or not.
Message-ID: <XFMail.011112162428.jhb@FreeBSD.org>
In-Reply-To: <200111122357.fACNvc507188@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.011112162428.jhb>