From owner-freebsd-threads@FreeBSD.ORG Tue Apr 29 06:10:40 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 5D05037B401; Tue, 29 Apr 2003 06:10:40 -0700 (PDT) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E95B43F75; Tue, 29 Apr 2003 06:10:39 -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 h3TDAb6U075179; Tue, 29 Apr 2003 16:10:37 +0300 (EEST) (envelope-from narvi@haldjas.folklore.ee) Received: from localhost (narvi@localhost)h3TDAadU075176; Tue, 29 Apr 2003 16:10:37 +0300 (EEST) Date: Tue, 29 Apr 2003 16:10:36 +0300 (EEST) From: Narvi To: Peter Wemm In-Reply-To: <20030429041716.A14182A7EA@canning.wemm.org> Message-ID: <20030429145307.L40030-100000@haldjas.folklore.ee> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: jdp@freebsd.org cc: threads@freebsd.org cc: Daniel Eischen 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 13:10:40 -0000 [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. > Cheers, > -Peter > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com > "All of this is for nothing if we don't go to the stars" - JMS/B5 >