From owner-freebsd-threads@FreeBSD.ORG Mon Jan 24 21:04:56 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 CF13F1065709; Mon, 24 Jan 2011 21:04:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A3DE18FC2D; Mon, 24 Jan 2011 21:04:56 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4741A46B09; Mon, 24 Jan 2011 16:04:56 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4980F8A009; Mon, 24 Jan 2011 16:04:55 -0500 (EST) From: John Baldwin To: David Xu Date: Mon, 24 Jan 2011 16:04:21 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201101241604.21451.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 24 Jan 2011 16:04:55 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: threads@freebsd.org Subject: 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: Mon, 24 Jan 2011 21:04:56 -0000 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. -- John Baldwin