Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Aug 2002 09:27:24 -0700 (PDT)
From:      John Polstra <jdp@polstra.com>
To:        hackers@freebsd.org
Cc:        eischen@pcnet1.pcnet.com
Subject:   Re: Help needed. Deadlock in rtld makes openoffice build hang ag
Message-ID:  <200208071627.g77GROKJ058301@vashon.polstra.com>
In-Reply-To: <200208071623.g77GN5K0002117@mail.pcnet.com>
References:  <200208071623.g77GN5K0002117@mail.pcnet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
In article <200208071623.g77GN5K0002117@mail.pcnet.com>,
Daniel Eischen  <eischen@pcnet1.pcnet.com> wrote:
> > > 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. ]

I agree completely about spinlocks vs. mutexes, in principle.  But ...
the reason the rtld uses its own spinlock implementation is because
it cannot assume that the threads package is libc_r.  It could be
linuxthreads or some completely unknown threads package.  I don't
like the current solution in the rtld, but it's hard to come up with
something that works with arbitrary threads packages.

John
-- 
  John Polstra
  John D. Polstra & Co., Inc.                        Seattle, Washington USA
  "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa


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?200208071627.g77GROKJ058301>