libkse / libthr bugs?

[Daniel Eischen]

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