Date: Fri, 27 Jun 2003 23:52:00 -0700 From: David Schultz <das@FreeBSD.ORG> To: Mike Makonnen <mtm@identd.net> Cc: freebsd-threads@FreeBSD.ORG Subject: Re: libkse / libthr bugs? Message-ID: <20030628065200.GA10309@HAL9000.homeunix.com> In-Reply-To: <20030627224228.SLIN12592.out001.verizon.net@kokeb.ambesa.net> References: <20030627063513.BRUI16647.out006.verizon.net@kokeb.ambesa.net> <Pine.GSO.4.10.10306270650461.17094-100000@pcnet5.pcnet.com> <20030627224228.SLIN12592.out001.verizon.net@kokeb.ambesa.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030628065200.GA10309>