From owner-svn-src-user@FreeBSD.ORG Tue Nov 16 00:21:59 2010 Return-Path: Delivered-To: svn-src-user@freebsd.org Received: from alona.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id BE1671065670; Tue, 16 Nov 2010 00:21:58 +0000 (UTC) (envelope-from davidxu@freebsd.org) Message-ID: <4CE1CE92.5050608@freebsd.org> Date: Tue, 16 Nov 2010 08:21:38 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.21 (X11/20090522) MIME-Version: 1.0 To: Jilles Tjoelker References: <201011071349.oA7Dn8Po048543@svn.freebsd.org> <20101113151035.GB79975@stack.nl> <4CDF7F38.5010000@freebsd.org> <20101114181631.GA1831@stack.nl> <4CE0790B.3040706@freebsd.org> <20101115232238.GA32225@stack.nl> In-Reply-To: <20101115232238.GA32225@stack.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 16 Nov 2010 00:21:59 -0000 Jilles Tjoelker wrote: > 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). > > I don't like the idea, the VM code is already very complex, I would not add trouble code to VM system. If VM code should worry userland mutex code, it is a very bad design, it is cross-layer and dirty, and may be inefficient. In fact, this old Solaris behavior is discouraged in their new code. Also I think removing the robust mutex or setting it to EOWNERDEAD is incorrect by munmap or other VM code, because the file can be mapped into process again, also a mutex which has been initialized pthread_mutex_init can exit in file persistently, if I know it is in stable storage, why should I initialize it again ? If I map it into memory again, should VM code look the signature of userland mutex and create a robust entry in kernel ? this sounds crazy. > 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. So my question is if he know the memory is still being used by mutex code, why does he corrupt or unmap the memory ? he shoot his foot, it looks likes he memset(start_of_data_segment, 0, sbrk() - start_of_data_segment), suicide, nobody can help. >> 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. > > This is not practical for normal user, only the thread library developers may have capability to do it. So this is incorrect design. > The glibc implementation has a similar restriction, except that's "in > the same thread" instead of "in the same process". > Very dirty implementation. > 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. > > Yes, syscall is clean.