Fwd: Use turnstile to implement sx_lock

Max Laier max at love2party.net
Thu Dec 15 12:25:19 PST 2005


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 at freebsd.org>
> Date: 15-dic-2005 18.57
> Subject: Re: Use turnstile to implement sx_lock
> To: rookie at gufi.org
> Cc: freebsd-smp at 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 
attempt if there is a thread with a higher priority waiting to get a xlock.  
This does not mean that your approach doesn't work, but you have to keep this 
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 
> someone else has it, you just have no one to propagate the priority to.  

It seems to me that you are talking about the same things with slightly 
different implementation details.  It doesn't really matter much where the 
queue of slocking threads is kept as long as it is easily and efficient to 
update the turnstile's owner on sunlock.  In practice it should be easier to 
have it in the turnstile as well and I still don't really understand why you 
(rookie) do not want to change turnstiles.

> BTW, I don't think sx locks should use turnstiles, but a new rwlock 
> primitive that has a similar API.  The reason is that sx locks can be held 
> across sleep right now (and are often used that way), but a rwlock that uses 
> turnstiles won't be sleepable, just as mutexes aren't sleepable.

Agreed.

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-smp/attachments/20051215/4ed79532/attachment.bin


More information about the freebsd-smp mailing list