From owner-freebsd-threads@FreeBSD.ORG Tue Apr 29 08:20:08 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 BC02037B401 for ; Tue, 29 Apr 2003 08:20:08 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD92A43FA3 for ; Tue, 29 Apr 2003 08:20:07 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3TFK6Bg022939; Tue, 29 Apr 2003 11:20:06 -0400 (EDT) Received: from localhost (eischen@localhost)h3TFK5N6022934; Tue, 29 Apr 2003 11:20:06 -0400 (EDT) Date: Tue, 29 Apr 2003 11:20:05 -0400 (EDT) From: Daniel Eischen To: Narvi In-Reply-To: <20030429145307.L40030-100000@haldjas.folklore.ee> Message-ID: 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 15:20:09 -0000 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