From owner-svn-src-user@FreeBSD.ORG Sat Nov 13 15:10:37 2010 Return-Path: Delivered-To: svn-src-user@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6FCA10656CB; Sat, 13 Nov 2010 15:10:37 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 38D7D8FC15; Sat, 13 Nov 2010 15:10:37 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 33CE835A864; Sat, 13 Nov 2010 16:10:36 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 1677) id 1E9CE17349; Sat, 13 Nov 2010 16:10:36 +0100 (CET) Date: Sat, 13 Nov 2010 16:10:36 +0100 From: Jilles Tjoelker To: David Xu Message-ID: <20101113151035.GB79975@stack.nl> References: <201011071349.oA7Dn8Po048543@svn.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201011071349.oA7Dn8Po048543@svn.freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: src-committers@freebsd.org, svn-src-user@freebsd.org Subject: Re: svn commit: r214915 - user/davidxu/libthr/lib/libthr/thread X-BeenThere: svn-src-user@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the experimental " user" src tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 15:10:37 -0000 On Sun, Nov 07, 2010 at 01:49:08PM +0000, David Xu wrote: > Author: davidxu > Date: Sun Nov 7 13:49:08 2010 > New Revision: 214915 > URL: http://svn.freebsd.org/changeset/base/214915 > Log: > Implement robust mutex, the pthread_mutex locking and > unlocking code are reworked to support robust mutex and > other mutex must be locked and unlocked by kernel. The glibc+linux implementation avoids the system call for each robust mutex lock/unlock by maintaining the list in userland and providing a pointer to the kernel. Although this is somewhat less reliable in case a process scribbles over this list, it has better performance. There are various ways this list could be maintained, but the glibc way uses an "in progress" field per thread and a linked list using a field in the pthread_mutex_t, so if we want that we should make sure we have the space in the pthread_mutex_t. Alternatively, a simple array could be used if the number of owned robust mutexes can be limited to a fairly low value. Solaris robust mutexes used to work by entering the kernel for every lock/unlock, but no longer, see http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6296770 Someone complained about that implementation being too slow. -- Jilles Tjoelker