From owner-freebsd-current@FreeBSD.ORG Mon Nov 26 15:53:00 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AB6616A41B for ; Mon, 26 Nov 2007 15:53:00 +0000 (UTC) (envelope-from ups@freebsd.org) Received: from smtpauth04.prod.mesa1.secureserver.net (smtpauth04.prod.mesa1.secureserver.net [64.202.165.95]) by mx1.freebsd.org (Postfix) with SMTP id 7ADEA13C459 for ; Mon, 26 Nov 2007 15:53:00 +0000 (UTC) (envelope-from ups@freebsd.org) Received: (qmail 1460 invoked from network); 26 Nov 2007 15:26:18 -0000 Received: from unknown (66.23.216.53) by smtpauth04.prod.mesa1.secureserver.net (64.202.165.95) with ESMTP; 26 Nov 2007 15:26:18 -0000 Message-ID: <474AE5AE.4020301@freebsd.org> Date: Mon, 26 Nov 2007 10:26:38 -0500 From: Stephan Uphoff User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Julian Elischer References: <4749BB5B.7040801@elischer.org> <4749BBDE.6000107@elischer.org> In-Reply-To: <4749BBDE.6000107@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: rmlock question.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2007 15:53:00 -0000 Julian Elischer wrote: > Julian Elischer wrote: >> If I make an exclusive rmlock request on an rmlock that has a busy >> set of readers coming and going, do new readers wait for me to get >> my turn, or do I have to wait for a moment where there are no more >> readers before I get a go? > in fact if the requests are of the order > > reader, reader, writer, reader, reader, writer, reader > > is the order of evaluation defined? is it preserved? This is a bit of a tricky question to answer. Writers always acquire an internal mutex, disallow further readers to acquire the lock using the read lock fastpath and then wait until all current readers unlock the lock. ( During this wait priority is propagated from the writer to one reader at a time) The writer unlocks the rmlock by unlocking the internal mutex. If the reader fastpath is disabled , a reader acquires the internal mutex, grants itself the lock, enabled the reader fastpath and unlocks the internal mutex. (1) This means that on a contested rmlock the mutex locking order mainly influences the rmlock locking order. The internal mutex locking order is mainly dictated by the priority of the locking threads. However FreeBSD uses adaptive mutexes by default and the locking order of multiple threads spinning to acquire a mutex is undefined. So in your example the first writer (W1) will be blocked by the first two Readers (R1,R2) but will disable the read fast path and hold the internal mutex. W1 will block R3,R4,W2,R5 as they all need to acquire the internal mutex. If R1,R2 release the lock, W1 will become unblocked and eventually unlock the lock such releasing the mutex. At this time R3,R4,W2,R5 compete for the mutex and whoever wins is next in the locking order. Stephan (1) - Unless recursive read locks enabled and a current readers recursively locks it a second time. In that case the lock is (re)-granted without acquiring the internal mutex first