Re: deadlock in NPTL, FUTEX

[Paul Pluzhnikov]

Bernhard Ibertsberger <elgringo@gmx.at> writes:

> since Kernel 2.5 signals seems to contain some trickier
> pitfalls. "Native POSIX Threads Library" vs linuxthreads-0.10

This isn't new to NPTL; you could have encountered the exact same
deadlock with LinuxThreads.

> Investigating that issue i found:
> http://lwn.net/Articles/124747/

The article above deals with the kernel side of things, and have
absolutely nothing to do with your problem, which is entirely in
user space.

> * what exactly is the anatomy of the deadlock inside the libc and the
> * kernel?

Huh? The deadlock is inside libc; kernel has nothing to do with it;
and what exactly do you mean by "anatomy".

> Does it necessarily  need a pagefault or can the deadlock
> * occue depending on other circumstances?

Your test case doesn't encounter any pagefaults, and pagefaults
have nothing to do with calling non-reentrant functions.

> * where is the context between localtime() und vsprintf()?

Huh? You seem to use words like "context" and "anatomy" in a meaning
that is entirely unfamiliar to me.

> In the
> * source of localtime() i can't find anything (just to __tz_convert())?
> * where can i find further information concerning this problem?

What further information do you need?

Consider the following function:

  int x;
  void foo() { while (x) sleep(1); x+=1; sleep(60); x-=1; }

Do you understand that if this function is interrupted while it is
inside 'sleep(60)', and if the interrupt handler calls it again,
then this function (and the interrupt handler) will *never* make
any further progress?

If you understand that, then substitute 'x' with a mutex, and you'll
understand exactly the nature of deadlock you are observing.

> If i run the demo[2] in form
> $ ./printf-hang | grep t
> it deadlocks to although there are no calls to ctime.

ctime is not the only function in libc that needs a lock.

*Every* function that may need a lock may exhibit the same problem.

There is a very short list of functions that are guaranteed to not
show this problem, they are called async-signal safe. Neither ctime,
nor printf are on that list.

> This means the concurrent printfs to the (non-threadsave) stdout are enough to
> deadlock.

Stdout *is* thread safe, and so is printf. But printf is not
async-signal safe, and may deadlock if called from a signal
handler. Solution: don't do that.

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.