From owner-freebsd-hackers Wed Aug 7 9:27:31 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D319137B400 for ; Wed, 7 Aug 2002 09:27:27 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3A4943E4A for ; Wed, 7 Aug 2002 09:27:26 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g77GROf12861; Wed, 7 Aug 2002 09:27:24 -0700 (PDT) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.4/8.12.4/Submit) id g77GROKJ058301; Wed, 7 Aug 2002 09:27:24 -0700 (PDT) (envelope-from jdp) Date: Wed, 7 Aug 2002 09:27:24 -0700 (PDT) Message-Id: <200208071627.g77GROKJ058301@vashon.polstra.com> To: hackers@freebsd.org From: John Polstra Cc: eischen@pcnet1.pcnet.com Subject: Re: Help needed. Deadlock in rtld makes openoffice build hang ag In-Reply-To: <200208071623.g77GN5K0002117@mail.pcnet.com> References: <200208071623.g77GN5K0002117@mail.pcnet.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <200208071623.g77GN5K0002117@mail.pcnet.com>, Daniel Eischen wrote: > > > Why there is suddenly another thread ? 0x8081c00 has changed > > > to 0x804f000 ... > > > > > _thread_run->sig_defer_count stays forever 1 .... > > > > Hopefully, Daniel will be able to explain this. > > It must have got interrupted while in a critical section. > Something may have grabbed a spinlock that the thread needs > inside a critical section. > > Spinlocks are bad, and we have critical sections to prevent > this from happening. Every spinlock and spinunlock should > be protected by being contained in a critical region. For > the most part, you could argue that we don't need spinlocks > if we have critical regions (in the single process/single > KSE libc_r anyways). But there are consumers that use > spinlocks without being in a critical region (malloc is > one that I know about). > > With spinlocks, we don't know which thread owns the lock > when it is contested, so we can't switch to the right > thread in order to let it finish the lock protected region. > > Everything should be using mutexes outside of libc_r > itself. I'm not sure of the reasoning behind the use > of the spinlock in malloc() (it predates me), but I've > often wanted to change it to use a mutex. > > [ Critical regions aren't exported outside of libc_r, > which is why they aren't useable elsewhere. ] I agree completely about spinlocks vs. mutexes, in principle. But ... the reason the rtld uses its own spinlock implementation is because it cannot assume that the threads package is libc_r. It could be linuxthreads or some completely unknown threads package. I don't like the current solution in the rtld, but it's hard to come up with something that works with arbitrary threads packages. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message