Date: Wed, 14 Mar 2007 10:17:03 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: Julian Elischer <julian@elischer.org>, current@freebsd.org Subject: Re: [RFC] locking.9 Message-ID: <20070314101424.A60010@fledge.watson.org> In-Reply-To: <20070314042926.GA6013@garage.freebsd.pl> 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> <45F771E2.9050709@elischer.org> <20070314042926.GA6013@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 14 Mar 2007, Pawel Jakub Dawidek wrote: > I think it should be: > >> 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 > sx_lock ok ok ok-2 ok ok >> rw_lock ok no no ok-2 no-3 > rw_lock ok ok no ok-2 no > > And I'd sort the table a bit differently: spin, mtx, rw, sx[, sleep]. Hmm. I was thinking more along the lines of a table that compared properties and locks. I.e., horizontally feature, vertically lock type. Features would be things like "safe in interrupt handlers", "can perform unbounded sleep while holding", "supports multiple readers, not just exclusion", "priority propagation", etc. > BTW. I just wake up with a feeling that I did something wrong in my code. I > thought about it for a moment and it seems I'm right. When one always use > rw/sx locks this way: > > sx_xlock(); > /* do work */ > sx_downgrade(); > /* do work */ > sx_sunlock(); > > (the same for rw(9)) the lock will _never_ be shared, because one still > always acquire exclusive lock first, which serialize synchronization. Is my > thinking correct? If so, I think it's not very obvious, so we may want to > add a comment about such use to the manual page as well. FYI, one of the problems with "downgrade" as a primitive is that if you always acquire exclusively and then downgrade, you never get multiple shared readers, as all shared readers must first go through an exclusive stage. It only helps if you have threads entering as shared from inception. This is one reason why naively moving to reader/writer locks doesn't solve concurrency limits in the TCP input path. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070314101424.A60010>