From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 17 19:37:18 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 76D5216A420; Tue, 17 Jan 2006 19:37:18 +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 AF6EB43D45; Tue, 17 Jan 2006 19:37:17 +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 6290971 for multiple; Tue, 17 Jan 2006 14:35:54 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k0HJbFYa039971; Tue, 17 Jan 2006 14:37:15 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Daniel Eischen Date: Tue, 17 Jan 2006 14:37:13 -0500 User-Agent: KMail/1.9.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601171437.15995.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1244/Tue Jan 17 03:46:07 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: freebsd-hackers@freebsd.org, prime , kamalp@acm.org 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: Tue, 17 Jan 2006 19:37:18 -0000 On Tuesday 17 January 2006 14:00, Daniel Eischen wrote: > On Tue, 17 Jan 2006, John Baldwin wrote: > > On Monday 16 January 2006 00:08, Kamal R. Prasad wrote: > > > you mean, boosting the priority of a reader would be required to avoid > > > priority inversion, but difficult to implement? > > > > > > regards > > > -kamal > > > > > > On 1/14/06, John Baldwin wrote: > > > > I think you just kind of punt and do a best effort. Trying to manage > > > > a list > > > > of current read lock holders would be a bit PITA. > > > > Yes. The actual boosting is rather simple, it's keeping track of who has > > read locks that is ugly. > > Hmm, do you really care which or if all of the readers get their > priority boosted? Can't you just boost the priority of [any] one > of the readers, and when he releases the lock and the reader lock > count is still positive, boost the priority of another reader? > Keep doing this until all the current readers have released the > lock. In a perfect world you'd like to boost all of the readers, > but that's pretty hard without chaining together all the readers > and allowing for nested locks. > > I'm assuming that this is only needed when a [higher priority] > writer wants the read lock. Yes, that is one possibility, and is a more complex method than what Solaris uses. For now I'm just not doing any propogation for read locks in the hopes of having a simpler and _working_ implementation first that can then be experimented with further. :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org