From owner-cvs-src@FreeBSD.ORG Tue Apr 1 23:15:42 2008 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C00EB1065670; Tue, 1 Apr 2008 23:15:42 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D3F6E8FC25; Tue, 1 Apr 2008 23:15:40 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47F2C223.6010705@FreeBSD.org> Date: Wed, 02 Apr 2008 01:15:47 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Max Laier References: <200804012031.m31KVtKs000176@repoman.freebsd.org> <200804020025.57684.max@love2party.net> In-Reply-To: <200804020025.57684.max@love2party.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_rwlock.c src/sys/sys rwlock.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2008 23:15:42 -0000 Max Laier wrote: > On Tuesday 01 April 2008 22:31:55 Attilio Rao wrote: >> attilio 2008-04-01 20:31:55 UTC >> >> FreeBSD src repository >> >> Modified files: >> sys/kern kern_rwlock.c >> sys/sys rwlock.h >> Log: >> Add rw_try_rlock() and rw_try_wlock() to rwlocks. >> These functions try the specified operation (rlocking and wlocking) >> and true is returned if the operation completes, false otherwise. > > hmmm ... I'm certainly missing something here, but what's a possible > usecase for these? It seems there is not much you can do if you can't > obtain a rw_lock. I can understand the need for sx_try_* where you want > to avoid sleeping, but I can't figure out the need for it on a locking > primitive that will only spin or wait (not 100% sure about the > terminology here). This is especially strange for rw_try_wlock, unless > you plan to sleep manually on fail. But then again you'd have a good > chance that you have to do it over and over again if timing is > unfortunate. One situation is that try_[rw]lock can be used to bail out completely if you are doing something optional. e.g. you might have code that is doing some optimization like prefetching of data that can be just skipped if the lock (read or write) cannot be immediately obtained. Kris