From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 06:32:12 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 BAA2E16A41F; Mon, 12 Dec 2005 06:32:12 +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 0C8F243D4C; Mon, 12 Dec 2005 06:32:10 +0000 (GMT) (envelope-from jasone@canonware.com) Received: by lh.synack.net (Postfix, from userid 100) id C06265E48ED; Sun, 11 Dec 2005 22:32:10 -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 EDADC5E47EF; Sun, 11 Dec 2005 22:32:07 -0800 (PST) In-Reply-To: References: 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: Sun, 11 Dec 2005 22:28:30 -0800 To: Daniel Eischen 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: Johan Bucht , 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: Mon, 12 Dec 2005 06:32:12 -0000 On Dec 11, 2005, at 9:58 PM, Daniel Eischen wrote: > On Sun, 11 Dec 2005, Jason Evans wrote: >> I have been contemplating creating a separate spinlock API that >> doesn't require the threads library to track the spinlocks across >> fork. This would (if I understand correctly) remove the current >> static spinlock limitations. > > What about using pthread_atfork()? Aren't there potential ordering issues for that? It seems to me that the malloc pre-fork code would need to be run after any other pre- fork functions, in order to avoid potential deadlock, and that the malloc post-fork code would need to be run before any other post-fork functions, again to avoid potential deadlock. After looking at the spinlock code some more, it's no longer clear to me why the thread/thr_spinlock.c code uses a static array for spinlocks. It seems to me that it would work fine to allow the program to provide space for a spinlock and manually initialize it. This would remove the limitation on the number of spinlocks. >> As for supporting recursive spinlocks, I doubt that the overhead >> would be acceptable in general. If I could get rid of the need for >> the one recursive lock in malloc.c, I certainly would. =) > > Why do we need a recursive mutex? Can you not restructure the > code so that it is not needed? There is an internal arena that the malloc code uses for allocating internal data structures. In some cases, the internal arena has to recursively allocate. If there were no object caching, it might be possible to pre-allocate, such that recursion never happens, but given the object caching, it's difficult to reason about precisely what will occur internally for a single malloc/free operation. There are some other possibilities, but nothing I've thought of so far is simple or elegant. Fixing this would make all locking in the malloc code a bit cheaper, which is why it continues to bother me. Jason