From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 09:54:51 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 795C016A420 for ; Sun, 4 Dec 2005 09:54:51 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3AA643D55; Sun, 4 Dec 2005 09:54:50 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id jB49smjX005495; Sun, 4 Dec 2005 09:54:50 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4392BCED.3070500@freebsd.org> Date: Sun, 04 Dec 2005 17:54:53 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20050928 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Evans References: <0B746373-8C29-4ADF-9218-311AE08F3834@canonware.com> <4391569A.7080808@freebsd.org> <43924917.3070506@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: New libc malloc patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2005 09:54:51 -0000 Jason Evans wrote: > I just need simple (low overhead) mutexes that don't cause malloc to be > called during their initialization. umtx is light weight and fast and need not malloc. > I would have used pthread_mutex_* > directly, but cannot due to infinite recursion problems during > initialization. > Yes, I know current pthread_mutex implementations use malloc, I don't think it will be changed to avoid using malloc very soon. > As you pointed out, it's important to get priority inheritance right in > order to avoid priority inversion deadlock, so my hand-rolled spinlocks > weren't adequate. I need mutexes that are managed by the threads > library. The libc spinlocks appear to fit the bill perfectly in that > capacity. It seems to me that using umtx would actually be the wrong > thing to do, because I'd be circumventing libpthread's userland > scheduler, and it would be the wrong thing for libc_r, as you pointed > out. This approach would work for libthr, but perhaps nothing else? > umtx will work with libpthread, I can not find any reason why using umtx will cause deadlock, the userland scheduler can not propagate its priority decision cross kernel, and umtx is a blockable syscall. > I'd like to keep things as simple and general as possible. Is the > current implementation that uses libc spinlocks acceptable? > > Thanks, > Jason > > P.S. Why are libc spinlocks deprecated? > > Because we want other libraries use pthread mutex, if it can not be used widely and we have to use spinlock, it is really a bad taste. I think only the malloc has recursive problem. I tell you the fact, libpthread needs malloc to initialize spinlock, so you can not create spinlock dynamically in your malloc code. only libthr does not have the problem. libc_r also has priority inversion problem with your current mutex code. Regards, David Xu