Date: Tue, 16 Nov 2010 08:21:38 +0800 From: David Xu <davidxu@freebsd.org> To: Jilles Tjoelker <jilles@stack.nl> Cc: src-committers@freebsd.org, svn-src-user@freebsd.org Subject: Re: svn commit: r214915 - user/davidxu/libthr/lib/libthr/thread Message-ID: <4CE1CE92.5050608@freebsd.org> In-Reply-To: <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> <20101115232238.GA32225@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CE1CE92.5050608>