cvs commit: src/lib/libpthread/thread thr_private.h thr_sig.c

John Baldwin jhb at
Wed Nov 3 10:09:51 PST 2004

On Tuesday 02 November 2004 06:27 pm, David Xu wrote:
> John Baldwin wrote:
> >On Monday 01 November 2004 06:04 pm, David Xu wrote:
> >>Not every important,  I think I have another very important history
> >>bug in hand,  did you get my "fix famous libpthread conditional
> >>variable race condition" mail ? :-)
> >
> >Oooo, can I test it please?  We are still having problems with mono on
> > HEAD here at work.  I tried merging the changes in uthread_cond.c 1.32 to
> > libpthread but that seemed to make it worse.  The problems seem to be
> > that a signal handler is being run when the SYNCQ sflag is set (but the
> > thread is not on a cv or a mutex queue), and the handler calls sem_post()
> > which is supposed to be signal safe.  sem_post() tries to lock a mutex
> > and then bombs with the assertion failure.
> You can try:
> But it was not designed to fix the problem you have seen. :-)

This looks like it's trying to fix the same problem as uthread_cond.c rev 1.32 
in libc_r but in a different way.  The fix for libc_r was to always unlock 
the mutex instead of trying to keep it locked in some cases.  The kernel cv 
code works like this as well.  I have a patch that ports 1.32 of 
uthread_cond.c to thr_cond.c if you are interested.

John Baldwin <jhb at>  <><
"Power Users Use the Power to Serve"  =

More information about the cvs-src mailing list