From owner-freebsd-threads@FreeBSD.ORG Wed Apr 16 22:43:39 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 759E337B401 for ; Wed, 16 Apr 2003 22:43:39 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C040D43FDD for ; Wed, 16 Apr 2003 22:43:38 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3H5hcBg006838; Thu, 17 Apr 2003 01:43:38 -0400 (EDT) Received: from localhost (eischen@localhost)h3H5haDL006828; Thu, 17 Apr 2003 01:43:36 -0400 (EDT) Date: Thu, 17 Apr 2003 01:43:36 -0400 (EDT) From: Daniel Eischen To: Terry Lambert In-Reply-To: <3E9E197A.6CD504E2@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: libpthread patch X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 05:43:39 -0000 On Wed, 16 Apr 2003, Terry Lambert wrote: > Daniel Eischen wrote: > > On Thu, 17 Apr 2003, David Xu wrote: > > > Hmm, I don't like to put malloc calling under critical section, > > > it is better to put it under a lock, otherwise this would cause dead > > > lock. suppose that an user thread is calling malloc(), and heap manager > > > got malloc spinlock, then it does somethings and the thread is preempted > > > by upcall from kernel, now UTS switches to another thread, that thread > > > starts to call pthread_create, so UTS kernel enters a critical region first, > > > and calls malloc, this would cause dead lock, because UTS is under critical > > > region and no context switch could happen. > > > > Hmm, I see what you mean. We could put spinlock in critical region > > and that may solve the problem, but I eventually want to see spinlocks > > go away and replace the very few that we have in libc with mutexes. > > Critical sectioning AND locking are a bad idea. They are > orthogonal technologies which are intended to solve the same > basic problems. The critical section is to prevent the thread from being swapped out by the kernel and sent to another KSE. That's it; it's not meant to do the same thing as locking. There's per-kse stuff that needs to be accessed that isn't correct if the thread gets run on another KSE, regardless of whether or not a lock protects it. If it wasn't possible for the kernel to send completed threads from one KSE to another (within the same KSE group), we probably wouldn't need critical sections (at least as currently implemented). -- Dan Eischen