Date: Wed, 7 Aug 2002 12:23:05 -0400 (EDT) From: Daniel Eischen <eischen@mail.pcnet.com> To: hackers@freebsd.org, jdp@polstra.com Cc: deischen@freebsd.org, mb@imp.ch Subject: Re: Help needed. Deadlock in rtld makes openoffice build hang ag Message-ID: <200208071623.g77GN5K0002117@mail.pcnet.com>
next in thread | raw e-mail | index | archive | help
> > Why there is suddenly another thread ? 0x8081c00 has changed > > to 0x804f000 ... > > > _thread_run->sig_defer_count stays forever 1 .... > > Hopefully, Daniel will be able to explain this. It must have got interrupted while in a critical section. Something may have grabbed a spinlock that the thread needs inside a critical section. Spinlocks are bad, and we have critical sections to prevent this from happening. Every spinlock and spinunlock should be protected by being contained in a critical region. For the most part, you could argue that we don't need spinlocks if we have critical regions (in the single process/single KSE libc_r anyways). But there are consumers that use spinlocks without being in a critical region (malloc is one that I know about). With spinlocks, we don't know which thread owns the lock when it is contested, so we can't switch to the right thread in order to let it finish the lock protected region. Everything should be using mutexes outside of libc_r itself. I'm not sure of the reasoning behind the use of the spinlock in malloc() (it predates me), but I've often wanted to change it to use a mutex. [ Critical regions aren't exported outside of libc_r, which is why they aren't useable elsewhere. ] -- Dan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200208071623.g77GN5K0002117>