From owner-svn-src-user@FreeBSD.ORG Mon Nov 15 23:22:39 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 B8DBE1065694; Mon, 15 Nov 2010 23:22:39 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 53A608FC1B; Mon, 15 Nov 2010 23:22:39 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 558C61DD6B2; Tue, 16 Nov 2010 00:22:38 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 1677) id 3E20417319; Tue, 16 Nov 2010 00:22:38 +0100 (CET) Date: Tue, 16 Nov 2010 00:22:38 +0100 From: Jilles Tjoelker To: David Xu Message-ID: <20101115232238.GA32225@stack.nl> References: <201011071349.oA7Dn8Po048543@svn.freebsd.org> <20101113151035.GB79975@stack.nl> <4CDF7F38.5010000@freebsd.org> <20101114181631.GA1831@stack.nl> <4CE0790B.3040706@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CE0790B.3040706@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: Mon, 15 Nov 2010 23:22:39 -0000 On Mon, Nov 15, 2010 at 08:04:27AM +0800, David Xu wrote: > I know the Solaris implemented in this way, but I also know because they > needs to look up a hash table in userland every time a pthread_mutex_lock() > is called, it is still not O(1), and has extra lock contention, even > worse, does > the userland hash table lock protect priority inversion ? is it safe for > real-time > thread ? I think they had implemented priority-inherited and > priority-protect > mutex, even their condition variable supports the real-time thread > scheduling. Hmm, true. I have another idea, please tell me why it won't work :) If a thread does pthread_mutex_init() for a robust mutex, store this fact in the kernel with the memory area (such that another process that maps the same area can see it as well). Upon pthread_mutex_destroy(), remove the entry. A sentence in POSIX.1-2008 mmap also allows removing the entry if the memory is no longer mapped in any process: ] The state of synchronization objects such as mutexes, semaphores, ] barriers, and conditional variables placed in shared memory mapped ] with MAP_SHARED becomes undefined when the last region in any process ] containing the synchronization object is unmapped. Provided applications obey this requirement, the kernel then has reliable information about what robust mutexes exist, which can be used to do the EOWNERDEAD thing. Some sort of userland-maintained kernel-accessible list of owned mutexes would be useful for efficiency (but not a linked list through the mutexes themselves). As far as I understand, unmapping a memory area containing a mutex is a programming error that is not required to be handled and may cause the lock to be stuck forever. > Their implementation also causes impossibility to use robust mutex without > thread library, I saw there is a complain of such a problem. I suppose you can still do it, provided you do not use any robust mutexes from the thread library in the same process. It requires replicating a lot of code from the thread library and is probably not portable across kernel versions, but it can be done. The glibc implementation has a similar restriction, except that's "in the same thread" instead of "in the same process". Lock/unlock as syscall seems about the only way to ensure people can roll their own robust mutexes and use them together with thread library robust mutexes. -- Jilles Tjoelker