From owner-freebsd-current@FreeBSD.ORG Sun Dec 4 03:47:24 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 CB63216A41F; Sun, 4 Dec 2005 03:47:24 +0000 (GMT) (envelope-from jasone@canonware.com) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0AD443D81; Sun, 4 Dec 2005 03:47:18 +0000 (GMT) (envelope-from jasone@canonware.com) Received: by lh.synack.net (Postfix, from userid 100) id 5A8695E48D1; Sat, 3 Dec 2005 19:47:18 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id ABDDE5E4885; Sat, 3 Dec 2005 19:47:16 -0800 (PST) In-Reply-To: <43924917.3070506@freebsd.org> References: <0B746373-8C29-4ADF-9218-311AE08F3834@canonware.com> <4391569A.7080808@freebsd.org> <43924917.3070506@freebsd.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jason Evans Date: Sat, 3 Dec 2005 19:46:01 -0800 To: David Xu X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 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 03:47:24 -0000 On Dec 3, 2005, at 5:40 PM, David Xu wrote: > The libc spinlocks are deprecated, in fact, thread libraries try to > keep track > off all spinlocks in libc and reset them in child process, they > will complain > if there are too many spinlocks, this is not very correct, but > would resolve > dead lock in real world applications (weird applications). > Because I see you have put _malloc_prefork() and _malloc_postfork() > hooks in thread libraries, I guess you want to manage all malloc > locks, so > you might don't need to use the spinlocks, you can implement these > locks by using umtx provided by kernel, you can use UMTX_OP_WAIT > and UMTX_OP_WAKE to implement these locks, the UMTX_OP_LOCK > and UMTX_OP_UNLOCK can also be used to implement locks, but I reserve > these two functions since I have plan to implement reliable POSIX > process > shared mutex. you can find those code in libthr to study how to > use umtx. > Last, I don't know if umtx will work with libc_r, but libc_r has > already been > disconneted from world for some days, it will rot away. I just need simple (low overhead) mutexes that don't cause malloc to be called during their initialization. I would have used pthread_mutex_* directly, but cannot due to infinite recursion problems during initialization. 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? 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?