Question about rtld-elf. Anyone?.. Anyone?

Daniel Eischen eischen at pcnet1.pcnet.com
Tue Apr 29 08:20:09 PDT 2003


On Tue, 29 Apr 2003, Narvi wrote:
> [snip]
> 
> > ...
> > This is a short-term fix for a larger problem.  The use of spinlocking
> > isn't guaranteed to work in all cases.  For example, if the spinning
> > thread has higher priority than all other threads, it may never be
> > pre-empted, and the thread holding the lock may never progress far
> > enough to release the lock.  On the other hand, spinlocking is the
> > only locking that can work with an arbitrary unknown threads package.
> >
> > I have some ideas for a much better fix in the longer term.  It
> > would eliminate all locking inside the dynamic linker by making it
> > safe for symbol lookups and lazy binding to proceed in parallel
> > with a call to dlopen or dlclose.  This means that the only mutual
> > exclusion needed would be to prevent multiple simultaneous calls
> > to dlopen and/or dlclose.  That mutual exclusion could be put into
> > the native pthreads library.  Applications using foreign threads
> > packages would have to make their own arrangements to ensure that
> > they did not have multiple threads in dlopen and/or dlclose -- a
> > reasonable requirement in my opinion.
> > ====
> >
> > Basically he's describing the exact scenario you're concerned about.  The
> > last paragraph suggests a better way.
> >
> 
> You will then need to make sure something sensible (and not a deadlock)
> happens if fork() gets called at a time when dlopen() / dlclose() is
> running in another thread.

How is this any different than spinlocks or mutexes used
in libc (malloc, free, etc)?

Yes, this is true, but no threads library that we have currently
tracks internal locks so they can be reinitialized after a fork.
It is possible that a fork() will leave things in the locked
state.  But even if they were locked, you'd only see a problem
if the forked program again became threaded.

We do need to fix this, and it is one of the things on my
TODO list.

-- 
Dan Eischen



More information about the freebsd-threads mailing list