From owner-freebsd-current@FreeBSD.ORG  Mon Nov 26 18:34:05 2007
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 7041F16A421
	for <current@freebsd.org>; Mon, 26 Nov 2007 18:34:05 +0000 (UTC)
	(envelope-from julian@elischer.org)
Received: from outP.internet-mail-service.net (outP.internet-mail-service.net
	[216.240.47.239])
	by mx1.freebsd.org (Postfix) with ESMTP id 5285F13C4D3
	for <current@freebsd.org>; Mon, 26 Nov 2007 18:34:05 +0000 (UTC)
	(envelope-from julian@elischer.org)
Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160)
	by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP;
	Mon, 26 Nov 2007 10:34:04 -0800
X-Client-Authorized: MaGic Cook1e
X-Client-Authorized: MaGic Cook1e
Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100])
	by idiom.com (Postfix) with ESMTP id 2B22F126AB0;
	Mon, 26 Nov 2007 10:34:04 -0800 (PST)
Message-ID: <474B1195.1020504@elischer.org>
Date: Mon, 26 Nov 2007 10:33:57 -0800
From: Julian Elischer <julian@elischer.org>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: Stephan Uphoff <ups@freebsd.org>
References: <4749BB5B.7040801@elischer.org> <4749BBDE.6000107@elischer.org>
	<474AE5AE.4020301@freebsd.org>
In-Reply-To: <474AE5AE.4020301@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: FreeBSD Current <current@freebsd.org>
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
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Nov 2007 18:34:05 -0000

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.


so the quick answer is:
 "request order is partially preserved, enough to ensure that lockout does not occur."



> 
> 
> 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
>