From owner-freebsd-threads@FreeBSD.ORG Tue Jan 25 16:17:13 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E041106566B; Tue, 25 Jan 2011 16:17:13 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D3D1B8FC0A; Tue, 25 Jan 2011 16:17:12 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 23A661A3C3F; Tue, 25 Jan 2011 08:17:12 -0800 (PST) Date: Tue, 25 Jan 2011 08:17:11 -0800 From: Alfred Perlstein To: Attilio Rao Message-ID: <20110125161711.GT21872@elvis.mu.org> References: <201101241604.21451.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: threads@freebsd.org, David Xu Subject: Re: Try upgrades and downgrades for POSIX rwlocks X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 16:17:13 -0000 * Attilio Rao [110125 08:09] wrote: > 2011/1/24 John Baldwin : > > Does anyone know if there is a de facto or proposed standard for supporting > > upgrades and downgrades in POSIX rwlocks? ??IBM seems to support something > > rather gross where a wrlock() will succeed if the only shared lock is held by > > the current thread. ??But then the thread holds both a read and write lock, and > > it has to call unlock twice, the first to drop the write lock, the second to > > drop the read lock. ??If we were to add support for upgrades and downgrades I > > would prefer something more along the lines of our in-kernel APIs where there > > are try_upgrade() and downgrade() operations that convert a given lock between > > states. > > I'd support us adopting the same semantic rwlock in kernel space have. > An alternative semantic would be what lockmgrs do: > - try to upgrade > - if failed (more than one shared owner then): > * drop our shared lock > * try a normal exclusive acquisition > > That seems like more linear, even if I'm very much more in favor of > not having something like that (infact, removing LK_UPGRADE is one of > my personal target, as such operation can be implemented in consumers > themselves as well, if they want). In my opinion the implicit drop semantic is really an error prone API and makes the code hard to read. I agree the LK_UPGRADE stuff is scary. -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer