Date: Sat, 28 Jun 2003 10:14:57 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: David Schultz <das@FreeBSD.ORG> Cc: freebsd-threads@FreeBSD.ORG Subject: Re: libkse / libthr bugs? Message-ID: <Pine.GSO.4.10.10306281009430.24063-100000@pcnet5.pcnet.com> In-Reply-To: <20030628065200.GA10309@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10306281009430.24063-100000>