From owner-freebsd-smp@FreeBSD.ORG Thu Dec 15 17:57:25 2005 Return-Path: X-Original-To: freebsd-smp@freebsd.org Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 114D116A41F for ; Thu, 15 Dec 2005 17:57:25 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44F4D43D66 for ; Thu, 15 Dec 2005 17:57:23 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3874580 for multiple; Thu, 15 Dec 2005 12:55:13 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBFHuqG9070481; Thu, 15 Dec 2005 12:57:09 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: rookie@gufi.org Date: Thu, 15 Dec 2005 12:57:21 -0500 User-Agent: KMail/1.8.2 References: <1fa17f810512150652h5da6a6a5g3347f841a614689e@mail.gmail.com> <200512151017.12168.jhb@freebsd.org> <3bbf2fe10512150817s346d621do@mail.gmail.com> In-Reply-To: <3bbf2fe10512150817s346d621do@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512151257.22004.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1210/Thu Dec 15 10:23:22 2005 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-smp@freebsd.org Subject: Re: Use turnstile to implement sx_lock X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2005 17:57:25 -0000 On Thursday 15 December 2005 11:17 am, rookie wrote: > 2005/12/15, John Baldwin : > > You have to add a second queue to the turnstile and make priority > > propagation > > still work, etc. Mutexes would just use the exclusive queue all the time > > whereas rwlocks would use both queues. This is the hard part of the > > rwlock project. I've sort-of started on this but haven't gotten very far > > at all in my jhb_lock p4 branch. > > 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 > 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. 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. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org