From owner-freebsd-threads@FreeBSD.ORG Fri Jun 27 23:52:05 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 7499237B404; Fri, 27 Jun 2003 23:52:05 -0700 (PDT) Received: from HAL9000.homeunix.com (ip114.bella-vista.sfo.interquest.net [66.199.86.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68B2944013; Fri, 27 Jun 2003 23:52:04 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.9) with ESMTP id h5S6q2iP011076; Fri, 27 Jun 2003 23:52:02 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.9/Submit) id h5S6q0r0011075; Fri, 27 Jun 2003 23:52:00 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Fri, 27 Jun 2003 23:52:00 -0700 From: David Schultz To: Mike Makonnen Message-ID: <20030628065200.GA10309@HAL9000.homeunix.com> Mail-Followup-To: Mike Makonnen , deischen@freebsd.org, freebsd-threads@freebsd.org, marcel@xcllnt.net References: <20030627063513.BRUI16647.out006.verizon.net@kokeb.ambesa.net> <20030627224228.SLIN12592.out001.verizon.net@kokeb.ambesa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030627224228.SLIN12592.out001.verizon.net@kokeb.ambesa.net> cc: deischen@FreeBSD.ORG cc: marcel@xcllnt.net cc: freebsd-threads@FreeBSD.ORG Subject: Re: libkse / libthr bugs? 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: Sat, 28 Jun 2003 06:52:05 -0000 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. BTW, as you probably know already, POSIX only requires a handful of functions to be async-signal safe, and even malloc/free aren't among them...