From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 18 18:03:01 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CB3316A422; Wed, 18 Jan 2006 18:03:01 +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 2C41D43D45; Wed, 18 Jan 2006 18:02:59 +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 6374115 for multiple; Wed, 18 Jan 2006 13:03:57 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k0II2vZ5056163; Wed, 18 Jan 2006 13:02:57 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org, rookie@gufi.org Date: Wed, 18 Jan 2006 12:34:17 -0500 User-Agent: KMail/1.9.1 References: <3bbf2fe10601180715k25297666y@mail.gmail.com> <3bbf2fe10601180831r69dbf1f9j@mail.gmail.com> In-Reply-To: <3bbf2fe10601180831r69dbf1f9j@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601181234.19349.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1245/Wed Jan 18 11:57:44 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Daniel Eischen Subject: Re: How priority propagation works on read/write lock? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2006 18:03:01 -0000 On Wednesday 18 January 2006 11:31, rookie wrote: > 2006/1/18, Daniel Eischen : > > I assume we already know how to propagate priority for mutexes, so > > once you know how to propagate for RWlocks, it all just works. > > As I can see, propagate priority for mutex needs a little modify to > turnstiles code, that's not a great deal. > > > Yes, once you choose a thread to propagate, you have to keep > > propagating through whatever it is blocked on or until you > > reach a point where the propagated priority is <= the priority > > of the next thread in the heirarchy. I never questioned that > > part of it, just the need to do it for all threads owning the > > RW lock at the same time. > > Maybe it's not "strictly" necessary but please consider that "blocking > hierarchies" are never too long and a total priority propagation would be > quicker (you however need to propagate to every owner in the end so doing > it at the same time could craft a bottleneck if the hierarchy is too long, > but it's a rare case and in the opposite way you need to rule 'what thread > needs to be update' every time a blocking thread is unblocked). One thing you need to think about is allowing for the fact that a thread might hold multiple read locks of the same lock (i.e., recursion) and it can hold read locks of more than one read lock. Your current use of a field in struct thread to link together the list of read owners for a lock won't work in the case of a thread holding a read lock of two different rw locks. This is why I think it is too hard to keep track of all the readers. Otherwise you have to provide storage somewhere else for the list of threads and it needs to not use malloc or rwlocks will be intolerably slow. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org