Date: Thu, 15 Dec 2005 21:25:09 +0100 From: Max Laier <max@love2party.net> To: rookie@gufi.org Cc: freebsd-smp@freebsd.org Subject: Re: Fwd: Use turnstile to implement sx_lock Message-ID: <200512152125.16004.max@love2party.net> In-Reply-To: <3bbf2fe10512151109w22ef9e2aj@mail.gmail.com> References: <1fa17f810512150652h5da6a6a5g3347f841a614689e@mail.gmail.com> <200512151257.22004.jhb@freebsd.org> <3bbf2fe10512151109w22ef9e2aj@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart7416933.bpJBzqqVCP Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 15 December 2005 20:09, rookie wrote: > Maybe you're not subscribed to smp@ Indeed I'm not - fixed. > What do you think about? See below. > ---------- Forwarded message ---------- > From: John Baldwin <jhb@freebsd.org> > Date: 15-dic-2005 18.57 > Subject: Re: Use turnstile to implement sx_lock > To: rookie@gufi.org > Cc: freebsd-smp@freebsd.org > > On Thursday 15 December 2005 11:17 am, rookie wrote: > > I'm working on the same problem too and I found another solution > > beacause, in order to mantain a clean design, maybe modifying > > turnstiles code is not the better idea. > > If we have a thread trying to slock it just blocks if sx is held in > > "exclusive mode" by another thread so it's enough a simple turnstile > > as for other blocking locks and we have nice priorty propagation. The After some thinking this strikes me as wrong. You must not grant a slock=20 attempt if there is a thread with a higher priority waiting to get a xlock.= =20 This does not mean that your approach doesn't work, but you have to keep th= is=20 in mind. > > real problem is when we try to xlock. A xlocking thread blocks if sx > > is held in "shared mode" (even by different owners) so we might > > mantain a track of every slocking thread (through a tailqueue, a > > static array or whatever) in order to have a priority propagation for > > those. I think (I didn't implement yet) it can be done outside the > > turnstile context so it seems we don't necessary need to modify. > > Finally, we might consider one thing: turnstile has just one owner > > while we have (in the slocks) more than one and so what's the real > > owner? > > We could use a "head thread" per track which must be treacted > > carefully (EG: on slocking it we might switch the turnstile owner). > > > > What do you think about? > > As per the description, I suggest go reading up on rwlocks in Solaris > Internals. The method they use is turnstiles with 2 queues, and for an > rwlock that is read locked, they have the concept of the 'owner of record' > which is basically the first thread to acquire a read lock, and you just > bump their priority and no one else's. When they drop the read lock, if= =20 > someone else has it, you just have no one to propagate the priority to. = =20 It seems to me that you are talking about the same things with slightly=20 different implementation details. It doesn't really matter much where the= =20 queue of slocking threads is kept as long as it is easily and efficient to= =20 update the turnstile's owner on sunlock. In practice it should be easier t= o=20 have it in the turnstile as well and I still don't really understand why yo= u=20 (rookie) do not want to change turnstiles. > BTW, I don't think sx locks should use turnstiles, but a new rwlock=20 > primitive that has a similar API. The reason is that sx locks can be hel= d=20 > across sleep right now (and are often used that way), but a rwlock that u= ses=20 > turnstiles won't be sleepable, just as mutexes aren't sleepable. Agreed. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart7416933.bpJBzqqVCP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDodErXyyEoT62BG0RAqC2AJ9L6+yqLzTElEu7g/xEJpuVN+hF4wCfR+2y ZOnolCzgRX8Bp4Bkf3h3Trw= =Id6x -----END PGP SIGNATURE----- --nextPart7416933.bpJBzqqVCP--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200512152125.16004.max>