From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 17 21:22:38 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 2FA9A16A41F; Tue, 17 Jan 2006 21:22:38 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id D68C943D45; Tue, 17 Jan 2006 21:22:37 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.146]) ([10.251.23.146]) by a50.ironport.com with ESMTP; 17 Jan 2006 13:22:38 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <43CD601D.6040807@elischer.org> Date: Tue, 17 Jan 2006 13:22:37 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <1fa17f810601122232l25551bc5n4e4a01ff6b7921e@mail.gmail.com> <200601131422.15208.jhb@freebsd.org> <200601171311.20570.jhb@freebsd.org> In-Reply-To: <200601171311.20570.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 21:22:38 -0000 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. > > > I do wonder if it is worth while. it would require an internediated structure that would be simultaneously linked into a number of structures.. it would be linked into a list of "read locks held by this thread, and it would be linked into a list of "threads currently reading on this read lock" it would however be a rathe small item, and I can imagine that a cache of a thousand or so of these would probably do enough for the system. Something like: struct rwlock_nexsus { SLIST_ENTRY( rwlock_nexus) by_thread; struct thread *owner; SLIST_ENTRY (rwlock_nexus) by_lock; struct rwlock *locked; } on a x86 this would be 16 bytes long.. on an amd64, 32 bytes in a page of 4k (x86) you get 256 of them. that's quite a few considerring that we have only 4 processers or so running code at a time and you probably shouldn't be unscheduled while holding one..