From owner-freebsd-threads@FreeBSD.ORG Tue Apr 29 11:03:03 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DE8037B401 for ; Tue, 29 Apr 2003 11:03:03 -0700 (PDT) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7C7A43F85 for ; Tue, 29 Apr 2003 11:02:59 -0700 (PDT) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (localhost [127.0.0.1]) by haldjas.folklore.ee (8.12.3/8.11.3) with ESMTP id h3TI2w6U078341; Tue, 29 Apr 2003 21:02:58 +0300 (EEST) (envelope-from narvi@haldjas.folklore.ee) Received: from localhost (narvi@localhost)h3TI2wLN078338; Tue, 29 Apr 2003 21:02:58 +0300 (EEST) Date: Tue, 29 Apr 2003 21:02:58 +0300 (EEST) From: Narvi To: Daniel Eischen In-Reply-To: Message-ID: <20030429202837.L40030-100000@haldjas.folklore.ee> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 18:03:03 -0000 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 >