From owner-freebsd-threads@FreeBSD.ORG Sat Jun 28 07:15:00 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 5BD1837B401; Sat, 28 Jun 2003 07:15:00 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92EE84400D; Sat, 28 Jun 2003 07:14:59 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h5SEEvXh026317; Sat, 28 Jun 2003 10:14:58 -0400 (EDT) Date: Sat, 28 Jun 2003 10:14:57 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: David Schultz In-Reply-To: <20030628065200.GA10309@HAL9000.homeunix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@FreeBSD.ORG Subject: Re: libkse / libthr bugs? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2003 14:15:00 -0000 On Fri, 27 Jun 2003, David Schultz wrote: > On Fri, Jun 27, 2003, Mike Makonnen wrote: > > I'm glad you brought this last point up because that has been on my mind as > > well. Let's say an application is in one of the locked libc functions, receives > > a signal and calls that same libc function from it's signal handler. > > Furthermore, let's say that the thread had just aquired a lock in the libc > > funtion before handling the signal. When this thread called the same libc > > function from the signal handler and tried to aquire the same lock again, would > > it not deadlock against itself? > > This is interesting in that it mirrors a general issue that comes > up in the kernel. Specifically, the kernel needs to deal with the > problem where an interrupt handler tries to acquire a kernel lock > that is held by the thread it interrupted. Traditionally, Unix > has dealt with the problem using a technique analogous to what Dan > suggested, namely, by blocking the relevant interrupts while > accessing data structures that interrupt handlers might need to > use. That approach doesn't work on a multiprocessor, though, so > the usual fix is to simply accept the fact that an interrupt > handler may want a lock that's already held, and allow it to > block. The userland analogue of that, i.e. giving a thread > context to each signal handler, probably won't fly. ;-) > > Andersen had to deal with the issue of a thread (possibly the UTS) > being preempted while holding a lock in his Scheduler Activations > work. He solved the problem by having the UTS check at the time > of preemption whether the preempted thread was running in a > critical section, and if so, defer the preemption. However, > instead of explicitly enabling and disabling preemption all the > time, he used the trick of checking at preemption time whether the > PC fell within certain ranges. In practice, that's probably too > hard, but it works well in special cases, such as preventing the > UTS from deadlocking against itself. Andersen also talked about just setting a flag when a thread was in a critical region. Libpthread uses a similar method; right now there are a couple of things that denote a thread being in a critical region. Signals are not blocked while threads are in critical region; they are deferred (latched and handled once the critical region is exited). -- Dan Eischen