Date: Tue, 29 Apr 2003 21:02:58 +0300 (EEST) From: Narvi <narvi@haldjas.folklore.ee> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? Message-ID: <20030429202837.L40030-100000@haldjas.folklore.ee> In-Reply-To: <Pine.GSO.4.10.10304291115580.22104-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 29 Apr 2003, Daniel Eischen wrote: > 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)? > its not, really. locks in the dynamic linker usualy just make things a bit more interesting than locks elsewhere. > 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. > No, you would see the problem as soon as you tried to use a function that used a locked structure, depending on how the dynamic linker did thinks this might include any fiunction, including exec* - threads + forking gives you really fascinating problems. How do you know that say malloc state was consistent at the moment you forked? You really need per-subsystem cleanups so that you won't occasionaly fail miserably. Its not really the threads lib that can / should track locks, unless it comes with its own copy of the subsystems. > We do need to fix this, and it is one of the things on my > TODO list. > > -- > Dan Eischen >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030429202837.L40030-100000>