Date: Wed, 14 Mar 2007 05:29:26 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: Robert Watson <rwatson@FreeBSD.org>, current@freebsd.org Subject: Re: [RFC] locking.9 Message-ID: <20070314042926.GA6013@garage.freebsd.pl> In-Reply-To: <45F771E2.9050709@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> <45F771E2.9050709@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--ibTvN161/egqYuK8
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Mar 13, 2007 at 08:54:10PM -0700, Julian Elischer wrote:
> Julian Elischer wrote:
>=20
> >ok so how about I commit this to get us started and the nroff and
> >locking experts can take it from there.
>=20
> The first table I think may look like this (from quick reading.. but I ma=
y be wrong):
>=20
>=20
> 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)
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].
> *1 Recursion is defined per lock. lock order is important.
Lock order is always important, not only between the same lock types.
You also can't mix order of acquiring mtx and rw locks, etc.
> *2 readers can recurse tough writers can not. lock order is important.
I think John or Attilio are working on adding a flag which will allow
for recursion.
> *3 There are calls atomically release this primative when going to sl=
eep
> and reacquire it on wakeup (e.g. mtx_sleep(), rw-sleep() and
> msleep_spin).()
>=20
> *4 One can also use sx_sleep() which atomically release this primative
> when going to sleep and reacquire it on wakeup.
What's the difference between 3 and 4? {rw,sx}_sleep(9) fucntions are
quite new and I don't know if you can use then only while
writer/exclusive lock or also while holding reader/shared lock.
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.
--=20
Pawel Jakub Dawidek http://www.wheel.pl
pjd@FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
--ibTvN161/egqYuK8
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQFF93omForvXbEpPzQRAgxjAJ9gw0ez5JupJhX0JxcFSp/UywlfyQCfTrqR
XBOJcq5ydkK7I4GB3HzPl9w=
=L4vQ
-----END PGP SIGNATURE-----
--ibTvN161/egqYuK8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070314042926.GA6013>