From owner-freebsd-current@FreeBSD.ORG Mon Nov 26 19:16:27 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 55BCF16A41A for ; Mon, 26 Nov 2007 19:16:27 +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 34B7813C46E for ; Mon, 26 Nov 2007 19:16:26 +0000 (UTC) (envelope-from ups@freebsd.org) Received: (qmail 19397 invoked from network); 26 Nov 2007 19:16:23 -0000 Received: from unknown (66.23.216.53) by smtpauth04.prod.mesa1.secureserver.net (64.202.165.95) with ESMTP; 26 Nov 2007 19:16:23 -0000 Message-ID: <474B1B9E.2080703@freebsd.org> Date: Mon, 26 Nov 2007 14:16:46 -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> <474AE5AE.4020301@freebsd.org> <474B1195.1020504@elischer.org> In-Reply-To: <474B1195.1020504@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 19:16:27 -0000 Julian Elischer wrote: > Stephan Uphoff wrote: >> 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. > > Thankyou. That was the information I was looking for. > I assume then that the order that the order that the remainign threads > contest the lock is: > R5, R3, W2, R4 > > then that the cycle repeats and W2 will wait for R5 and R3, > and R4 will wait for W2. Yes > > > so the quick answer is: > "request order is partially preserved, enough to ensure that lockout > does not occur." > Yes, the answer catches the spirit of the issue. This being said high priority writers could indefinitely block access to low priority readers. ( But then you really should not be using rmlocks) Stephan