Date: Mon, 12 Nov 2001 16:34:52 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
To: John Baldwin <jhb@FreeBSD.org>
Cc: freebsd-arch@FreeBSD.org, Robert Watson <rwatson@FreeBSD.org>, Terry Lambert <tlambert2@mindspring.com>
Subject: Re: cur{thread/proc}, or not.
Message-ID: <200111130034.fAD0YqV07450@apollo.backplane.com>
References: <XFMail.011112162428.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
: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?
I was thinking non-chained hash on the object address. Real simple.
(((int)ptr >> 5) ^ (int)ptr) & MASK or something like that. Or something
even simpler... basically something we can play around with and optimize
later without breaking the API we've constructed.
: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. :)
Yes I think the addition of a mtx_pool_find() call is excellent! A
wonderful example of horizontal expansion (rather then vertical
complexity, or vertical complication if I'm being cute).
-Matt
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?200111130034.fAD0YqV07450>