Date: Mon, 12 Nov 2001 16:30:49 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
To: Julian Elischer <julian@elischer.org>
Cc: John Baldwin <jhb@FreeBSD.ORG>, Terry Lambert <tlambert2@mindspring.com>, Robert Watson <rwatson@FreeBSD.ORG>, freebsd-arch@FreeBSD.ORG
Subject: Re: cur{thread/proc}, or not.
Message-ID: <200111130030.fAD0Unn07434@apollo.backplane.com>
References: <Pine.BSF.4.21.0111121608240.94926-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200111130030.fAD0Unn07434>