Date: Tue, 2 Nov 2004 18:40:37 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: David Xu <davidxu@freebsd.org> Cc: John Baldwin <jhb@freebsd.org> Subject: Re: cvs commit: src/lib/libpthread/thread thr_private.h thr_sig.c Message-ID: <Pine.GSO.4.43.0411021838240.5097-100000@sea.ntplx.net> In-Reply-To: <418817ED.2040201@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 3 Nov 2004, 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: > http://people.freebsd.org/~davidxu/kse/thr_cond.c.diff > > But it was not designed to fix the problem you have seen. :-) I think if _kse_critical_leave() were replaced by _kcb_critical_leave() at around line 676 in thr_kern.c, that should fix the problem, no? There's no reason to do a yield check after leaving the scheduler, and the check for signals and cancellation is done right after that point before returning. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0411021838240.5097-100000>