From owner-freebsd-threads@FreeBSD.ORG Wed Apr 16 20:21:49 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 C6A6F37B41D for ; Wed, 16 Apr 2003 20:21:49 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42E5343FBF for ; Wed, 16 Apr 2003 20:21:49 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0039.cvx40-bradley.dialup.earthlink.net ([216.244.42.39] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 195zxp-0007ck-00; Wed, 16 Apr 2003 20:21:30 -0700 Message-ID: <3E9E197A.6CD504E2@mindspring.com> Date: Wed, 16 Apr 2003 20:03:22 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Eischen References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a48534a8a8ca45d257b9394e9a1406c47e387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c 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 03:21:50 -0000 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. You guys need to decide whether you are locking code paths or if you are locking data objects. Pick one and only one, and stick with it consistently, or you will shoot your feet. So far, the FreeBSD 5.0 locking has been pretty schitzophrenic. -- Terry