Date: Tue, 16 Nov 2010 00:22:38 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: David Xu <davidxu@freebsd.org> Cc: src-committers@freebsd.org, svn-src-user@freebsd.org Subject: Re: svn commit: r214915 - user/davidxu/libthr/lib/libthr/thread Message-ID: <20101115232238.GA32225@stack.nl> In-Reply-To: <4CE0790B.3040706@freebsd.org> References: <201011071349.oA7Dn8Po048543@svn.freebsd.org> <20101113151035.GB79975@stack.nl> <4CDF7F38.5010000@freebsd.org> <20101114181631.GA1831@stack.nl> <4CE0790B.3040706@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101115232238.GA32225>