Date: Tue, 13 Mar 2007 20:54:10 -0700 From: Julian Elischer <julian@elischer.org> To: Julian Elischer <julian@elischer.org> Cc: Pawel Jakub Dawidek <pjd@freebsd.org>, Robert Watson <rwatson@FreeBSD.org>, current@freebsd.org Subject: Re: [RFC] locking.9 Message-ID: <45F771E2.9050709@elischer.org> In-Reply-To: <45F73AE7.6010508@elischer.org> References: <200703092241.l29Mf2Ds062856@repoman.freebsd.org> <200703121535.22140.jhb@freebsd.org> <20070312200345.GB5688@garage.freebsd.pl> <200703121618.41084.jhb@freebsd.org> <45F5E1F9.5090806@elischer.org> <20070313010309.Q25395@fledge.watson.org> <45F73AE7.6010508@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote:
>
> ok so how about I commit this to get us started and the nroff and
> locking experts can take it from there.
>
The first table I think may look like this
(from quick reading.. but I may be wrong):
The following table shows what you can and can not do if you hold one of
the synchronisation primatives discussed here: (someone who knows what
they are talking about should write this table)
You have: You want: Spin_mtx Slp_mtx sx_lock rw_lock sleep
SPIN mutex ok no no no no-3
Sleep mutex ok ok-1 no ok no-3
sx_lock ok no ?? no ok-4
rw_lock ok no no ok-2 no-3
*1 Recursion is defined per lock. lock order is important.
*2 readers can recurse tough writers can not. lock order is important.
*3 There are calls atomically release this primative when going to sleep
and reacquire it on wakeup (e.g. mtx_sleep(), rw-sleep() and
msleep_spin).()
*4 One can also use sx_sleep() which atomically release this primative
when going to sleep and reacquire it on wakeup.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45F771E2.9050709>